Introduction
Modeling a process involves various stages and requires particular elements.
In particular, these stages and elements are:
A process definition.
An understanding of processes in BPM.
The process Development steps.
A knowledge about the modeling approaches.
Process Definition
The definition of the process must meet the following parameters:
- Specific order of events and activities that aim for a certain goal
- The events and activities have strictly defined inputs and outputs
- The events and activities are connected in a process and eventually produce a value
The following elements are essential to process modeling:
- An event that makes the process start.
- Activities to be performed.
- Decisions to be taken.
- A final result of the process flow.
- Exceptions that may occur during the process.
In the SAP NetWeaver Developer Studio (NWDS), the Process Modeling perspective is used to sketch processes (the business view). The is used to make the process executable (the developer view).
Processes in BPM
The Process Composer adopts the Business Process Modeling Notation (BPMN) to enable easy and intuitive modeling of end-to-end business process. You use the defined in the BPMN specification flow objects, connecting objects, artifacts and swimlanes to create a business process model.
Modeling in the Process Composer allows you to create more than just a descriptive model of a standard business process, but also provides capabilities for you to foresee and model possible exceptions. You can also model exceptions handling to visualize how the process branches after an exception has occurred.
Apart from creating a process model, the Process Composer allows you to define the business logic behind it, which makes the process model executable. To do that, the process composer integrates the SAP specific development and standard project development allowing the consumption of Web services, the usage of Web Dynpro (WD) and Visual Composer (VC) user interfaces (UI), the usage of Adobe offline forms, and the usage of rules and functions in process modeling. Web services assigned to process model automated activities allow a step in the process modeled using an automated activity to be executed through starting a Web service. WD, VC UIs and Adobe offline forms assigned to tasks that are modeled as human activities, enable a human to interact with the process and execute tasks. Rules and functions provide strong capabilities regarding decision making and transformation of data required in the process model.
Another key feature of the Process Composer is that all Web services, UIs, tasks and rules, and functions are reusable units. You can use all of them in different projects and models, which enhances flexible process modeling. Also, you can develop custom reusable units corresponding to your business needs.
Using the Process Composer, you model different processes based on different scenarios. For example, you can model a business trip approval scenario, a leave request approval scenario, a goods delivery scenario, and so on.
Process Development Steps
The following steps are involved in process development:
- Defining the business process.
- Modeling the process (that is, the sequence of process steps).
This step includes modeling flow objects, artifacts, and swimlanes.
- Defining the business logic and data flow.
Defining the business logic includes importing and assigning service interface definitions, creating and assigning tasks, and importing and assigning data types.
Defining the data flow includes creating sequence flow connections and data flow connections. - Compiling and deploying the business process model.
This step involves installing the process definition and runtime engine.
Modeling Approaches
The figure shows the three different modeling approaches.
Top-down Modeling Approach
The top-down approach focuses on the overall process. It starts with defining the overall business requirements that give the framework of the business process model. After that the model that describes how a requirement is fulfilled is split to separate business processes. Each of these processes has its specific activities and the activities include, on their side-specific services and tasks. The goal of the model, is to depict a broader view of a business process fulfilling a given requirement but not to show how a specific activity is performed. This broader view helps business analysts and managers to see how the overall process goes, where it needs improvements, and whether any elements are missing in the general process. On the other side, a top-down process model that does not focus on the subprocesses’ characteristics and activities does not allow you to see how the subprocesses and their activities behave in reality.
In the Process Composer, you can use the top-down approach to model a process according to the requirements of a specific business case. The starting point is defining a general overview of the process and the process steps.
With this approach, the process modeling includes the following steps:
- Creating a process.
- Creating the process steps, represented by activities.
- Creating an importing the business logic of the process steps (tasks, Web services, rules).
Top-down Approach Guidelines are:
- Vertical approach.
- Depicts a broader view of a business process fulfilling a given requirement, but not to show how a specific activity is performed.
- Focuses on the overall process-starts with defining the overall business requirements as a framework for the business process model.
- Support business analysts and managers in process improvement efforts and functionality gap analysis.
Bottom-up Modeling Approach
In contrast to the top-down approach, the bottom-up approach starts with defining the activities that stand at the base of the process model. Using them, many different and detailed business processes are created, describing how low level business requirements are fulfilled. The goal of the model is to show how a specific activity is performed to produce a value at the end of the process. In other words, this approach focuses on the subprocesses first. This detailed view of them helps developers and system architects to make the process work. However, a problem occurs when this abundance of details has to be combined to form the overall model picture or when it comes to defining the key requirements the general model should fulfill.
In the Process Composer, you can use the bottom-up approach to model a process focusing on the details of the process steps. After defining the process steps details, that is to say the business logic of the steps, you can combine them to create the process model.
With this approach, the process modeling includes the following steps:
- Creating and importing the business logic of the process steps (tasks, web services, rules).
- Creating a process.
- Creating the process steps, represented by activities.
Bottom-up Approach Guidelines are:
- Vertical approach.
- Shows how a specific activity is performed to produce a value at the end of the process.
- Starts with defining the activities that stand as the base of the process model.
- Uses many different business processes, describing how low level business requirements are fulfilled.
- Supports developers and system architects who make the process work.
Inside-out Modeling Approach
Unlike the top-down and bottom-up approaches, which are a rather vertical type of modeling, the inside-out one is a horizontal approach. It consists of defining key processes in the overall process and then complementing them with other processes. This approach may be helpful to modelers in different areas in case none of the vertical approaches is appropriate. Like both other approaches, this one has its downsides as well. One of them is that when using this approach, there might be difficulties in defining what the key processes are.
In the Process Composer, you can use the inside-out approach and represent the key processes in the overall process as subprocesses. You can represent a complex task as a subprocess if you want to focus on the task as one of the key processes in the model. You can later add to the subprocess some human and automated activities, which could act like additional small processes whose details are not important.
Inside-out Approach Guidelines are:
- Horizontal approach to define key processes in the overall process and then complementing them with other processes.
- Support modelers in different areas, in case none of the vertical approaches is appropriate.
- Key processes represented in the overall process as subprocesses.
- Complex tasks represented as subprocesses, if the tasks are key processes in the model.
- Human and automated activities added to the subprocess, which act like additional small processes whose details are not important.
