In the business process modeling phase, the main objective is to develop the process model, which will define the existing process flow in detail. The transparency of the process flow is crucial as this gives the process owners, process analysts, and all others involved an insight into what is going on. An understanding of the AS-IS process flow also ensures that we can judge the efficiency and the quality of the process.
The main objective of process modeling is the definition of the AS-IS process flow. We will model the business process to satisfy the following objectives:
To specify the exact result of the business process and to understand the business value of this result.
To understand the activities of the business process. Knowing the exact tasks and activities that have to be performed is crucial to understanding the details of the process.
To understand the order of activities. Activities can be performed in sequence or in parallel, which can help improve the overall time required to fulfill a business process. Activities can be short-running or long-running.
To understand the responsibilities and identify (and later supervise) who is responsible for which activities and tasks.
To understand the utilization of resources consumed in the business process. Knowing who uses which resource can help improve the utilization of resources as resource requirements can be planned and optimized.
To understand the relationship between people involved in the processes and their communication. Knowing exactly who communicates with whom is important and can help to organize and optimize communications.
To understand the document flow. Business processes produce and consume documents (regardless of whether they are paper or electronic documents). Understanding where the documents are going and where they are coming from is important. A good overview of the documents also gives us the opportunity to identify whether all the documents are really necessary.
To identify potential bottlenecks and points for improvement, which can be used later in the process optimization phase.
To introduce quality standards, such as ISO 9001, more successfully and to better pass certification.
To improve the understandability of quality regulations that can be supplemented with process diagrams.
To use business process models as work guidelines for new employees who can introduce themselves to the business processes faster and more efficiently.
To understand business processes, which will enable us to understand and describe the company as a whole.
A good understanding of business processes is very important for developing IT support. Applications that provide end-to-end support for business processes can be developed efficiently only if we understand the business processes in detail.
Efficient process modeling requires a modeling method that provides a structured and controlled approach to process modeling. Several modeling methods have been developed over the years. Examples include IDS Sheer's ARIS methodology, CSC's Catalyst, Business Genetics, SCOR and the extensions PCOR and VCOR, POEM, and so on.
Process modeling also requires a notation. Business Process Model and Notation 2 is the most comprehensive notation for process modeling thus far. It has been developed under the hood of Object Management Group. We will provide a detailed introduction to BPMN in Chapter 3, BPMN for Business Process Modeling.
With version 2, BPMN adds a crucial aspect—support for executable processes. Prior to BPMN 2, business processes were more or less diagrams. With version 2, BPMN has added the ability to execute BPMN process models on a process server. This way, BPMN process models have become even more valuable assets for each information system. The ability to execute BPMN models is nowadays supported by leading process servers, including Oracle BPM Suite. Support for executable processes has brought about another useful feature, that is, the ability to export BPMN process models into the interchangeable XML format, which means that, at least in theory, BPMN business processes are not dependent on a specific tool of the process server.
Until now, we have talked about strictly defined business processes. Such processes are common for scenarios where activities, the order of activities, roles, and other elements of the process are well defined and do not change often. Such processes are commonly used for scenarios where we want to standardize the work and make sure that all follow the same template.
Not all processes can be well defined in terms of strict process models. Business processes that require knowledge, work, and certain expertise usually cannot be modeled in terms of activities and transitions (such models would be too complex). Therefore, the alternative way of modeling such processes has been defined. It is called adaptive case management or advanced case management.
In contrast to traditional, rigid process modeling, in ACM, the activities within an adaptive process are identified. However, the transitions between the activities are not modeled. The transitions are either defined as rules, or it is up to the knowledge workers to identify the right order of activities for a certain case. However, the tools that support ACM should provide the ability to monitor, update, understand, and interpret every activity as it is processed. We will talk more about ACM in Chapter 9, Adaptive Case Management.
The AS-IS process model for each business process consists of the top-level process model, which shows the high-level activities and the flow of these activities, along with the responsibilities of the roles involved in the process. It also includes detailed process maps for each high-level activity, with detailed representations of process activities. The detailed process map may have several decomposition levels depending on the complexity of each high-level activity.
Special attention should be placed on the exception-handling diagram. When modeling a business process, it is very important that we don't end up modeling only the optimal process flow (happy flow). We must not forget to identify the possible exceptions that might occur and specify how these exceptions are handled. An exception-handling diagram shows exactly this.
A well-designed process model should define at least:
The process trigger, which tells us how the process is triggered to start the execution
The necessary input information required in the process
The process result or results
Roles involved in the process or responsible for the process
Responsibilities of the roles within the process, such as responsible-for, executes, participates, supervises, and so on
Metrics used for measuring process efficiency
Events that can interrupt the regular process flow and the compensation logic required to handle these interruption events
Compliance with standards or reference processes
The business goals a process contributes to
When designing the process, it is also particularly important that we identify not just the regular process flow but also the exception flow that each process has.
If an exception occurs, it should be handled. The exception-handling diagram shows how to handle these exceptions. We should specify how exceptions are handled, by whom, and where the process goes to after the exception has been handled.
Often, exceptions require that we compensate activities of the process flow that have already been completed successfully. We might also want to compensate activities if an event interrupts the process flow.
When modeling business processes, our objective should be to develop sound process models. Soundness of the process models can be achieved if we follow a few basic principles:
Syntax: Our model must have correct syntax as defined by the modeling notation. If we use BPMN, we should follow the BPMN syntax rules. Most tools can check the syntax.
Semantics: Our model should also be semantically correct. This means that we have included all relevant activities, decisions, events, documents, and other elements. This also means that the process flow is correct and we have defined how to react to events, how to handle exceptions, and how to compensate if necessary. We should also use the correct names for all elements. Achieving semantic correctness is more difficult than achieving syntactical correctness.
Relevance: We should model only those processes that are relevant to the problem domain. In modeling processes, we could easily get carried away because one process will typically relate to other processes. Sometimes, it is difficult to draw a line between what we should include and what we should not. The most basic principle is to include only those artifacts that are relevant from the perspective of the process and the problem domain we are focusing on. Too much modeling is a waste of time.
Cost versus benefit: We model processes to achieve specific benefits. We should therefore weigh the amount of effort against the anticipated benefits. Usually, the 80/20 rule applies here as well. 80 percent of the benefit comes from 20 percent of the effort, and vice versa. Therefore, it is important to know the level of detail and when it is better to stop modeling. The required level of detail can differ. If we perform process modeling for quality assurance, a lower level of detail is required than if we perform process modeling for an SOA implementation.
Usability: The model should be usable and understandable. Otherwise, the model is worth nothing. Business processes are complex. To achieve usability, we should decompose the model into various levels of detail. How we do the decomposition is important as the parts should be understandable. We usually prefer simple models over more complex ones.
Standards: While modeling business processes, we should use and apply certain standards. First, we should use good practices and patterns. Second, we should use naming conventions. In some industries, standard or reference process models exist (such as eTom for telecom operators). We should look for compliance if it can add business value.
Integration: We should integrate different models that look at the same or similar process domains from different perspectives. The integrated model will reveal all aspects of the process. We should also design a process map where all processes and relationships between them are listed.
Using these and a few other, more specific principles will help make our process models better and more usable over a longer period of time. We should, however, be aware that modeling processes is not easy although it might look easy at first sight. Therefore, in the next section, we will list common problems that we are likely to face.
When modeling business processes, we will face several challenges. We have identified some of these in the following paragraphs.
Modeling business processes should be aligned with the overall business strategy. If the objective of process modeling is not related to specific business goals, then it is a waste of time for all people involved. Therefore, it is crucial that we define, from the beginning, what the goals of process modeling are. The goal can be, for example, to provide end-to-end IT support for a specific process. The goal can also be to improve the efficiency of the process. It is, however, important that we do not stick to such high-level goals. We should precisely articulate the specific goals of the company. We should know the exact process for which we want to develop end-to-end support, where we want to improve the efficiency, and by how much. Without clearly defined goals with measurable outcomes, we should not start process modeling.
When we start process modeling, we should clearly define the responsibilities. In process modeling, people from different organizations participate. They must see value in participating, otherwise, they will not be willing to dedicate their time. Communicating the benefits of process modeling is, therefore, important. Even more important is to have support from the top management. Only the top management can order all employees to participate in the project.
We should define teams that will participate in the process modeling. Here is one possible structure of the team, which has proven to be efficient:
Process owner
Two persons, coming from the same department, to assist the process owner
Process quality representative
Business process analyst (or analysts)
IT representative
Optionally, an external consultant
We also have to define measurable goals to assess whether process management has been done the right way and what the benefits have been.
An important part of business process modeling is communicating the models to all interested parties. This includes company management, unit management, supervisors, employees, quality assurance, and all other interested employees, all of whom can use the process model to better understand what is going on within the organization. They can also use the process model as work instructions.
Publishing the process model and communicating it to all interested employees is also important because, this way, we can gather feedback on the process and improve it even further. Publishing a process on the company's intranet is usually a good way to give visibility to process models.
Feedback on process models can improve quality and can be a good source of ideas for improving and optimizing the process. This is the first step in building continuous awareness about processes and their optimization among process owners and all others involved in the process.
Oracle BPM Suite 12c provides rich process reports that can be used not only for documentation and analysis, but also for communication. We will show how to use process reports later in this book.