This blog will introduce the foundations of business process modeling using a standard-based approach. In this article's series, we will discuss the concepts of using Business Process Model and Notation 2 (BPMN2), a standard developed by the Object Management Group (OMG). BPMN has become the de facto standard for modeling business processes. With version 2, it has gained the capability not only to model but also to execute processes—thus, it has become an executable language, which allows modeling business processes on different levels of decomposition, from strategy modeling all the way to modeling executable business processes.
Business process modeling is aimed at capturing a range of information pertaining to how a business works and making this information available to a wide variety of stakeholders. This means that processes mapped in BPMN should easily be comprehensible across the organizational hierarchy. BPMN is therefore designed to cover a wide array of usages in its notation and allows the modeling of end-to-end business processes.
In general, BPMN can be used to model business processes, which are also called orchestrations. Furthermore, BPMN can be used to model choreographies and collaborations:
- Business processes (orchestrations) include:
- Private business processes
- Private non-executable (internal) business processes
- Private executable (internal) business processes
- Public business processes
- Choreographies
- Collaborations, which can include
- Processes and/or
- Choreographies
In most cases, as in this book, BPMN is used as a standard notation designed to model most kinds of processes used in an organization. Today, most organizations use BPMN to create a process repository for all of their processes. Hence, the range of processes mapped by BPMN can be categorized depending on the business usage, as described in the following sections.
Strategic or operational
Based on the level of a given business process, it could be categorized as strategic or operational. Typically, an organization will define high-level strategies, which will be decomposed to lower levels until a representation that can be implemented is reached.
As explained in the previous chapter, strategy modeling is supported in BPM Suite using strategy models. For example, gaining leadership status in online retail in the UK could be a strategic intent of an organization. These business strategies are further decomposed to a set of goals, which, if fulfilled, will help achieve the strategy. For example, reducing item delivery time can be one of the goals.
At the next level, we usually define the main business functions of an organization that are instrumental in the achievement of the goals. These business functions are typically represented using block diagrams. In BPM Suite, enterprise maps can be used. For example, to reduce item delivery time, the main business function to focus on would be the 'supply chain department', and other functions such as marketing and sales, which are part of the end–to-end order to cash process.
At this level, we can also have very high-level business process diagrams to provide an abstract view of the end-to-end operational process. Such processes will typically go through a series of decompositions before they reach an implementable stage.
These activities will again be further decomposed to add more details to the business process diagrams until we reach a stage where we can expose these business process diagrams to a BPM for implementation.
Process type
A business process can also be classified based on its type and the extent of the requirement for automation. In the BPM world, processes can be categorized as human-centric processes that mainly require human intervention for the process to move from one state to another. An example of such a process could be an underwriting process in insurance, where the underwriter needs to gather customer information before deciding on the insurance coverage and premiums. Similarly, there could be processes that are more automated, say a financial trading process, where the trade settlements between parties could be automated by integrating multiple systems to ensure minimal human intervention. Processes can also be categorized according to some other factors, such as how document-centric the process is or whether the process requires ad hoc case management. The categorization of the process in this manner is typically done during the initiation of a BPM project as the choice of the technology platform will depend on the process types (technology providers are still consolidating their offerings to cover all aspects of process automation).
Process scope
Typically, the business process scope could be limited to the organization. This is called a private business process. A business process could also be a collaboration process that involves interfacing with external parties, such as customers, suppliers, partners, and so on. This is called a public process.
In the case of private processes, the scope is to map out the operational processes for process improvement and implementation. Examples of private processes are the employee performance appraisal process, the ordering process, or the car rental process that we are using throughout this book. Private processes can be executable or non-executable.
In the case of public processes, where external parties interact with the organization process, the scope becomes larger, and this will require careful thinking about how the process choreography will happen across various external entities. In this case, all of them will have their own application infrastructure, which in turn, will pose its own interoperability challenges. In BPMN, a public process represents these interactions or sequence of activities as message flows and highlights the touch points between the entities involved. Typically, standards such as RosettaNet, ebXML, and so on would be mapped to a public process defined in BPMN.
