Implementing a BPM Solution for Service Organizations
Implementing a BPM Solution for Service Organizations
Take a look at how effective adding automation to your business process management system can be in increasing overall agility.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Business Process Management is an effective way not only to cope with today's dynamic business needs with agility but also assists in continuous process improvement in a structured way following the BPM lifecycle. Whether it is to turn around a flagging organization or raising the bar of your existing organization in order to stay ahead of competitors, you need to continuously improve and optimize your business processes. The faster you can bring about this change, the more successful you are. Adoption of business process management, therefore, offers a number of benefits to business – primarily improved business agility, higher efficiencies, better visibility and more importantly the ability to measure performance directly from process execution. According to James Harrington, “Measurement is the first step that leads to control and eventually to improvement.”
Figure-1: BPM Life Cycle
Figure 1 depicts the BPM lifecycle. In this article, we’ll cover three of the five phases in the Business Process Management lifecycle, while focusing on implementation of the execution and monitoring phases using a simple framework.
Most application development starts with defining the business requirement document containing functional use cases, business processes and other non-functional requirements. Traditionally, this document along with the business process flows in graphical format are handed over to the systems analyst or developer for implementation. Figure 2 below illustrates and compares two approaches to implement a business process automation solution.
Figure 2: Approaches to Process Automation
The traditional development approach on the left assumes the developer is a superman who magically translates those business processes and other requirements into code, which is then executed within an application server. This step is a bit fuzzy and depends entirely on the skills of the developer. Also, whenever there is a change in the business process, the business user or analyst needs to rely on the developer to reflect the change. Worse still, tracking changes in processes and co-relating it to the executing code is a cumbersome process with little or no clarity on the correct version of the process that is currently executing on the application server.
A modern approach illustrated on the right-hand side splits the development task depending on the skills within the team. Business analysts and users who are well versed with the business logic and rules are responsible to design the business process and rules artifacts. Note these artifacts unlike the picture format in the traditional approach, are modeled using BPMN2 and are not translated into code. The structure of these processes is not modified by the developer or analyst but only enhanced by additional attributes. The developer, on the other hand, implements business code for all the tasks (user, service, script etc.) within the process as well as other infrastructure code such as persistence, interactions with other internal and external systems etc. Such a distribution of developmental efforts improves the quality of deliverables by leveraging the right skillsets and empowering respective stakeholders.
BPMN is a good choice when process flow can be defined in advance and the process progresses through predefined steps (predictable). However, if the sequence of activities is not well-defined or is context-driven (progression of activities decided at runtime), it comes under the purview of case management. The Object Management Group (OMG) has released three core standards relating to processes modeling. As of this writing, BPMN 2.0 is the latest standard for modeling business processes. CMMN 1.1 is standard for case modeling and DMN 1.1 is the standard for modeling decision or rules. Business rules can be defined in a business-friendly way using DMN standard which closely resembles a spreadsheet.
Let’s see how business processes are automated with an example. Consider a simplified business process for “Loan Approval” modeled using the Camunda Process Modeler as shown in Figure 3.
Figure 3: Loan Approval Process (BPMN Format)
The two collaborating entities are the “Customer” and the “Loan Agency.” The Loan Agency has three roles (reviewer, approver and back office) performing tasks depicted within their respective swim lanes. Human tasks and service tasks are denoted by their respective icons. Timer events on the receive tasks trigger timeout events leading the process to the “Cancel” end state. The process is initiated by a “Submit Request” message from the customer. The process defined within the Loan Agency is marked as executable, while the customer tasks only interact with the process at defined interfaces and are not strictly part of the process.
Users or Groups associated with each human task are configured either statically or more often, dynamically through the application. A user form associated with each user task is displayed as soon as the execution reaches the user task in response to the user invoking his task from the pending task list. Each service task executes a piece of code that is associated with it whenever process execution arrives at that task. The other important place where the developer needs to code is at the interface between organization boundaries. Here, in this case, a call to the customer is made at the “Return to Customer” send task while it waits for a response from the customer at the corresponding “Receive Amended Request” receive task. These send and receive tasks use standard REST protocol to communicate with the customer application.
Notice the “Assign Reviewer” task in the model. This task is normally performed by a supervisor based on certain criteria. If those criteria can be clearly defined, then the human task could easily be replaced with an automated task based on certain defined rules. In the above model, the “Assign Reviewer” task has been implemented as a “Rule” task. Notice the icon of the rule task in contrast to a user task. Rule task helps cut down human resources and consequently gets rid of the wait times associated with such tasks significantly improving process cycle time. As illustrated in the Figure 4 below, business rules are defined in a simple spreadsheet format that can easily be modified by the business user. For instance, the first rule states that “If the loan amount is <20,000 then the review task is assigned to Wesley” and subsequently, the request moves to his task list and so on.
Figure 4: Business Rule for "Assign Reviewer" task (DMN format)
The Business Process that we just described is the centerpiece of the application. Other functions such as user interactions with task lists, persisting data to databases etc. are infrastructure code that can easily be consolidated into a framework to make it easier for the developer to create several similar applications. One such framework is described in the video presentation titled “Building Smarter Organizations for a Smart City – Part 6”. The framework layer discussed in the presentation shields the application developers from the nitty-gritty of interacting with the underlying process engine. The framework described in the presentation uses Camunda BPM as the process engine for executing business processes and rules.
Figure 5: Deployment of Business Process and Rules
Figure 5 above shows the business process modeled using the BPMN 2.0 standard and business rules modeled using DMN 1.1 standard both in XML format are deployed to the Process and Rules engine respectively. Business users and business analysts can modify process flows and rules on their own using the available modeling tools. These BPMN and DMN models are true executables and run within a specialized process engine while business specific code written by the developer executes on an application server.
A block schematic of the process automation architecture using a custom framework is shown in Figure 6 below. The custom framework layer encapsulates most of the infrastructure code such as task management, persistence, dashboards, integration with external systems as well as interactions with the process and rules engine, thereby easing the burden of developers.
Figure 6: Architecture for Process Automation
Applications along with their respective processes and rules are packaged and deployed to the application server independent of the other applications running on the framework as shown in Figure 7 below.
Figure 7: Deployment view of the process applications
Since processes from all applications are deployed and run within the same process engine, the framework is an ideal place to capture metrics from all processes running within it. Raw values emitted from the process during runtime are aggregated in a data warehouse in order to display on the dashboard. The dashboards feature different widget types depending on the metrics parameter.
Figure 8 below shows a snapshot of the process dashboard provided by the framework showing key metrics for the “Loan Approval” process. The left pane displays the process diagram of the selected process along with the number of running instances, current process version etc., while the right-hand pane shows instantaneous and trend values of critical metrics such as average response times, process throughputs, process statuses and average activity times aggregated over the selected time period in real time. When a new process is deployed to the process engine, relevant metrics are automatically added to the process dashboard.
Figure 8: Process Dashboard View
A functional dashboard shown in the Figure 9 below which is also part of the framework displays performance metrics of individual users for each process that he/she is part of. Metrics include average time spent by a user on specific tasks in each process, the percentage of time spent in each process, addressing some of the concerns of the functional managers.
Figure 9: Functional Dashboard View
Finally, the service dashboard displays a view into each of the active process instances in execution. Figures 10 and 11 below show the process status for a particular loan request. The “Process” tab on the lower pane shows the process in its visual form with the currently waiting task “Approve Loan” in this case, highlighted in green as well as the path traced by this instance so far. The “Details” tab shows specifics such as the process status, process instance attributes as well as the elapsed time for each user task within the process in chronological sequence.
Figure 10: Service Dashboard View (Waiting Status)
Figure 11: Service Dashboard View (Elapsed times)
In this article, we've seen how business processes can be automated using a process-oriented approach to application development. A custom framework could simplify development efforts considerably and deliver services with agility. While we've covered the process design, process execution, and process monitoring phases of the BPM lifecycle in this article, the two other phases, process modeling and process optimization, that helps in continuous process improvement will be covered later.
Opinions expressed by DZone contributors are their own.