In order to understand the concept that guides BPM, we must first begin by understanding all the concepts behind that name, and the first one we need to understand is the concept of process.
In the broadest sense, a process is a series of steps or transformations to achieve a specific objective in a particular context. Like any transformation, it needs to have something to transform and a well-defined desired output of the transformation.
For example, if we want to build a house, we need to follow a set of steps depending on the area of the house, the materials, any services available, and so on. The steps also depend on the outcome (house style) we want. Some of the steps can be done at the same time, while some need to wait for other steps to be finished.
The important thing is the coordination between those steps to perform the transformation in the way we intend to, and each step needs to be clear and concise. In short, for each transformation (process), we need to know all the steps required to achieve the required outcome (goal), which will be the desired result of a process. Usually, goals and objectives have the ultimate outcome of improving the revenue or production of a company, and can have multiple yet different end results, thereby improving the conditions of the business.
The knowledge of how to achieve the goal and the transformation steps are usually held by an expert in the context. I may probably have a basic idea about how to lift a few walls for a room, but for a real-life scenario, I may not be able to describe all the steps needed to make quality housing. If we really want to know about real-life processes, we need to talk to experts in that field. This expert knows how to deal with normal processes and also how to deal with specific or exceptional situations for a wide range of different houses and buildings.
The word business associated to the process definition can seem ambiguous, but it is mostly due to how abstract the concept of business really is. From a developer-friendly perspective, we can think of business as a particular domain or context, or group of contexts. It could be easily exchanged in this case for domain, field, company, company unit, and any lingo that specifies a defined area of work. Business processes need to be evaluated, analyzed, designed, modeled, and validated by people who understand the domain where those processes belong. Since there are different business roles within a company, each should know a different perspective of the same process. Then, the business process becomes a common point of interaction and a common language between those roles. Activities, decisions, events, and many different components will define the structure of the way a process that is relative to a business needs to be conducted.
It is important to notice that the goal of business processes is tightly associated to the business goals, objectives, and strategies. With all these considerations in mind, we can arrive to the following definition:
Business processes are a sequence of business activities done by business users and business applications (company or third-party systems) to achieve a business goal for the purpose of a specific increase in value from the business' perspective.
We'll analyze this definition in detail by splitting it into its three main concepts and covering them thoroughly.
An activity is a black box piece of work that contributes directly to achieving a business goal. We surely need to understand how the activity is performed. However, as we say, it is a black box, because from the process' perspective, the only things important are the inputs it needs and the outputs produced. The activity performed can be very simple or very complex, depending on the perspective of the process definition.
What is considered an activity in one process perspective can be composed of a group of low-level processes, which are in turn composed of a series of simpler activities. For example, a high-level process in a car factory can have an activity called "Build the Car's Engine", but from a lower-level perspective, activities could be detailed to the point of just telling a robotic arm to activate the weld for a second (one minuscule step in the car's engine preparation). In other words, a business process can be composed of multiple subprocesses.
Once you select a perspective or level for a particular process definition, you should stick to it for describing all activities regarding that specific process. You can call other lower-level processes from activities, so you can always go into more detail later. Besides, high-level strategic processes and low-level more technical processes will surely have different roles and experts behind them. A manager in a car factory might not be interested in having so much detail in their perspective, but an engineer would. Also, managers prefer to see the bigger picture, and tend to simplify their views to be able to cope with everything at once.
Usually, the low-level perspectives end up driving the operative end of the company, performing work such as the following:
Handling customer information
Documenting specific metadata
Invoking service notifications
In the end, all processes are tied together by high-level perspective processes, which end up providing information for decision making, managing, and coordination. High-level processes usually aggregate information about the general performance, possible improvements, or any sort of relevant information for management. We will see examples of subprocesses, role assignment, and different activity type handling when we cover process writing in Chapter 3, Using BPMN 2.0 to Model Business Scenarios.
The activity name is usually composed of the following:
A verb
A noun
Some examples of activity names are "Review Architectural Document", "Clean the Cutting Machine", "Analyze Client Risk", and so on.
It might seem a simple thing to put a name to an activity, but there are a few considerations to take beforehand. Remember that when you write a process, you are doing it from a particular perspective—whether it is a high level view of the whole company activity inside a process, or the flow of a very specific step performed by a company. Therefore, the activity name must make sense from that perspective. It wouldn't make much sense to name an activity "Rotate robotic arm elbow 45 degrees" in a high-level process, because its point of view should be much more abstract and wide.
Also, you should avoid any technical developer jargon in your activities' names. Remember that the process is thought to be a place for common language within a business or business unit, so the jargon used (if any) to write the process should be the jargon of that particular domain. It should be clearly understood by business users. In other words, try to avoid names such as the following:
Call
InternalWebService->getMyData()Execute batch command W-3302
REST call to
http://my.domain:8080/rest/esoteric-service
Also, try to avoid any terms that will make the process hard to read, like obfuscated IDs or out-of-scope terminology. Remember that depending on the process perspective, the people who will be interested in reading or updating such processes will be accustomed to different terminologies.
Business processes, at least when designed correctly, are not thought to be monolithic systems that cover everything, but coordination software between other systems (the business applications) and people (the business users). There are some differences in the way people and systems behave and also in the way they need to be coordinated.
Human activities represent the human interactions in our processes. In the BPMN 2.0 specification, they are called User tasks. Every time we have a person involved in our business processes, we will have a human activity in our processes to represent such interaction.
When we think of human interactions in our business process execution, we think of having a person or group of people involved in a set of activities that will produce a specific result; the human response time to complete such activities takes minutes, or hours, or days. So, the process engine must be prepared to handle such activities in a way it can wait for long periods of time for the result of the task by providing asynchronous management of those tasks in runtime configurations.
Systems, on the other hand, usually represent automatic responses. Compared to human activities, external system activities take very small amounts of time—usually ranging from milliseconds for the fastest cases to minutes for the slowest automated activities. Companies generally have a set of external systems exposed through well-defined interfaces that solve very specific problems. When we need one of these services' information, we can just call external systems (through service calls, event handling, or simple scripting) and get the results into the process.
However, it is worth mentioning that systems may not provide automatic responses, or may take a long time to respond. Because of this, and for many other reasons we will mention later on, we should try to consider as many tasks in our process as asynchronous tasks.
Systems can be classified based on their technical behavior as synchronous (the process engine will wait for the completion of a task, that is, a service invocation) or asynchronous (the system will continue its execution and wait for the external system to notify the process engine when the task is completed, that is, a thread-managed operation), while human interactions are intrinsically asynchronous. Also, systems can be classified, depending on their provider, as either internal or external third-party interactions.
Human interactions can be classified depending on the people involved in executing them. They can be performed by a specific role or group of roles within a company or domain, just one specific person, or maybe specified through a specific variable in the process. Examples of this classification would be the call center group of a company, customers, third-party users, and so on.
It's important to understand that these classifications are not important from the process engine perspective. All the engine will deal with is a name mapping of a particular group of activities to their implementation. The classification is useful mostly from the point of view of maintenance and documentation, which helps to know the ownership of each application/system in order to understand how the interaction will be made.
The most important part of the business process definition is achieving a goal. It's the sole reason for the process' existence; without it, the process has no purpose at all. This should never be forgotten.
The business goal of a process shouldn't be disruptive or impossible to accomplish in any way in the selected business process perspective. Each business process definition must define a clear goal and all the activities must be defined in order to contribute to achieving said goal.
Mixing goals and perspectives is a common mistake that you need to avoid when you model your first business processes. For example, when defining the process of building a car in an automated factory, we might use the same process to define the steps a robotic arm should follow to make a simple weld, overcomplicating the process. When this happens, it's recommended to split the business process definition into multiple well-scoped processes for the sake of understandability and maintainability.
One way of achieving this difficult task is to create a brief textual description of the process' main responsibility, its ownership, and the concrete goal that it was designed to achieve. This brief description can be used to train new people to understand why the process is useful to the company. You will also end up with a self-documented process that can be used by the company to improve quality levels.