BPMS
In the past days I was reading the Paul Harmon’s excellent book “Business Process Change” (1), in particular the chapter about software systems supporting Business Process Management activities, and I found it was a good time to write down some notes on software systems that fall into category referred Business Process Management System – BPMS. So, here it is a series of two articles based on Paul Harmon book, but also based on “Fundamentals of Business Process Management” book (2), as well as some considerations from my personal experience.
This is the first article in the series, where the concepts regarding BPMS systems are given. In the second article I would like to deep into a BPMS that is really on the market.
Introduction
In process-oriented organizations, i.e. those organizations managed through a process approach, business process change initiatives aim to design or redesign business processes to improve the performances or to continuously align operative processes to the organizational strategies, which organizations can implement to maintain successful competitive on the market. To implement these initiatives, it cannot ignore the use of software systems that go by the name of Business Process Management System – BPMS. In fact, as we will see later in more detail, these are able to support all stages of the business processes life cycle, not just automation.
Business Process Management Systems
A definition of BPMS that I like, because it includes all the features that an evolved BPMS normally makes available, is the one provided on BPTrends site: “A suite of software tools that lets analysts or software developers create and monitor the ongoing execution of a business process. In essence these tools are workflow tools extended for modern software environments. A BPMS suite includes tools for analysis, for design, and for runtime execution. They often incorporate business rule capabilities and analytics, and they usually provide managers with information about the ongoing execution of the process.” (3)
BPMS Architecture
The following figure schematically presents the typical architecture of a evolved BPMS, with features that makes available (4):
The Utilities level can be broken down primarily into four component modules.
Process Modelling Environment is the functional component that typically allows business analysts to graphically define the as-is model and to-be process conceptual model, also called a business oriented process model, which is useful in the analysis and design/redesign phases of the process. Some BPMS make Simulation features available that allow, through the use of statistical functions and constructions of different scenarios, to anticipate any problems, or to evaluate the results on the performance of different choices on the processes (e.g. assignments of more or less resources on a task, different control flows).
Development Environment is the environment where IT people, application developers, complete the process conceptual model with the attributes and technical/operational details that are required to obtain the execution process model, that is, the automated process that goes to compose the bpms software application. In this environment, graphical interfaces are also realized that allow an iteration between the users and the instance of the process in which the data, related to the business/document entity (complaint, loan request, document, etc) managed by the process, is displayed and managed. Also, this is the environment where interfaces are built, typically via data or services, for the integration and coordination of the bpms application with other company’s systems or external to it.
Process Monitoring Environment is the module that provides, typically to process owners or line business managers, features that allow to monitor in real time the operational performance of all the processes running in the organization. Also, it provides statistical information, reports and summary data resulting from the aggregation and processing of historical data related to the executions of processes in a given period of time.
Management Environment is the environment where a business role, as a system administrator, defines basic configurations that apply to all BPMS managed business processes, such as configuring the e-mail service, defining alerts, defining automatic task cycles, managing users. It is the environment where you can consult the logs resulting from the execution of processes for the detection of any anomalies or trends in progress.
Engine is the core element of the BPMS.
Workflow Engine is the software element that manages the execution of process instances at runtime, ensuring that the steps are traversed as defined by the model control flow, that the tasks are routed to their responsible, that they can interact with the process-managed document based on their profile, that the defined email notification/alert is sent, which executes the scheduled events. One of the tasks performed by the engines is the production of work-lists (task lists) that lists the activities of the different running processes that require the attention or intervention of a user.
Enterprise Application Interface – EAI Engine provides all the features that allow the process instance to run the interfaces defined between the bpms application and other software systems. Rules Engine is the module that, at the decision points of the process control flow, determines what is the relevant business rules then examines it to determine what the outcome of the decision is.
Some BPMS, particularly those that have specialized in an industrial sector, for example, banking, insurance, quality, pharmaceutical, have added to their systems a layer of Knowledge that allows them to develop bpms applications more easily and quickly by making available, in a pre-packaged and ready-to-use way (of-the-shelf), for example, business rules, process models presented as industry best practices, standard connectors with other systems, ready-to-use application frameworks or that need only minimal customizations.
Process Life Cycle
From what has been said so far, it is clear how the most advanced BPMS systems can cover and support the the entire business process life cycle (5):
In the Analysis phase, they allow you to create as-is process model and to document performance, or other organizational objectives unsatisfied, resulting from qualitative and quantitative analyses of the processes. In the Design, they allow you to realize the conceptual to-be process model that defines solutions to the problems identified in the previous phase. In this and the previous phase the most used formalism for the realization of the models is the BPMN standard that all major BPMS support.
All BPMS guarantee the functions for the Implementation phase in which we move to digitization, to the automation of business processes, which is precisely the primary goal of BPMS. At this stage, to-be process conceptual models are enriched with operational and technical details which were not useful or necessary in conceptual models but are needed to realize bpm software applications. At this stage the language used may still be the BPMN but each BPMS provides programming languages, standard or their own, libraries or frameworks to realize quickly and in a simple way, we also talk about low-code and citizen developer, bpm applications. In the Run&Monitor phase, bpms workflow engines run instances of executable processes. Execution data is recorded in databases to monitor active processes in real time, to detect bottlenecks, delays, and other events, or to provide statistical and process summary data, visualized in dashboards panel, based on historical data from executed processes.
Some BPMS also support, what can be called the Definition of di Business Process Architecture phase, or even Process Discovery (2). In this phase the main result is Business Process Architecture Diagram in which the main business processes of the organization’s value chain are identified, their hierarchical relationship is defined and the business process’s key performance indicators are identified. But, it must be said that this is a border area with another category of software systems called Enterprise Architecture Solutions (or Organization Modeling Solution) that one day I would like to elaborate with you in another article.
Other BPMS include Process Mining features, which in the context of bpms projects, can contribute to the analysis phase, to identify and define the flow of control of the process, and in the monitoring phase by emphasizing the process model. Again, there are software tools dedicated to process minining techniques and functions. For a first in-depth look at this topic, I refer you to the Process Mining Manifesto (6).
Finally, we must say two words about Robotic Process Automation – RPA, a technology that in the Implementation phase is bringing significant benefits in terms of the performance of business processes, allowing to fully automate repetitive manual activities, governed by fixed and well-coded business rules, thus freeing up human resources for more high value-added tasks. Many BMPS has specific connectors to integrate and coordinate Bots-type activities, developed with specific software tools, into the end-to-end process’s control flow.
BPMS and Business Activity Monitoring System
We have said that BPMS normally provide an environment dedicated to monitoring the performance of processes. These measures, graphically presented (histograms, pie chart, etc) in a more dashborad, depending on the purpose and the target users, can be classified into three categories: operational, tactical, and strategic.
Operational process dashboards target line managers who have operational responsibility for day-to-day processes, so they typically show measurements of instances of processes that are still running or just concluded. For example, a dashboard may display the number of cases that are on time or overdue. Other dashboards may have activity-related measures (e.g. where there are bottlenecks) or resources committed to them (e.g. resource occupancy percentage, number of homes pending to a resource).
Tactical process dashboards target process owners, functional managers. “The purpose of tactical dashboards is to give a picture of the performance of a process over a relatively long period of time (e.g., a month or quarter or even a year) in order to put into evidence undesirable performance variations and their possible causes, long-term bottlenecks and deviations, or frequent sources of defects. Typical measures displayed in a tactical process dashboard include number of completed cases, cycle time, waiting times, processing times, resource utilization, cost per case, and defect rate. For a given performance measure, a tactical dashboard may display statistics such as the minimum, maximum, mean, and standard deviation of this measure, or the entire distribution of the performance measure in the form of a histogram.” (2)
Strategic process dashboards target executive managers. Their purpose is to visualize summaries of consolidated data, relating to more or less large time periods. In these dashboards, measures are normally directly related to the strategic actions decided by management, therefore, which can be useful in confirming these decisions or making changes in strategy. For this type of monitoring, data from BPMS automated processes is only one of the necessary sources, in fact, other data, such as sales, ordering, forecasting, number of complaints, coming from other business systems or even files on file servers, are necessary. These data are collected and recorded in the datawarehouses, built ad hoc from the company specifications, to finally realize Business Intelligence application, which in addition to presenting the measurements in dashboards, allow you to navigate them, to understand the links, to deepen results root causes:
Finally, I have to mention a new type of monitoring, the Predictive Process Monitoring, which some BPMS are proposing in their monitoring modules. An example of a software tool that can offer this type of monitoring is Nidirzati:”Nirdizati is an open-source web-based predictive process monitoring engine for running business processes. The dashboard is updated periodically based on incoming streams of events. However, unlike classical monitoring dashboards, Nirdizati does not focus on showing the current state of business process executions, but also their future state (e.g. when will each case finish). On the backend, Nirdizati uses predictive models pre-trained using data about historical process execution.” (7)
Advantages of using a BPMS
In this paragraph we go to explain what are the benefits adopting a BPMS. The first advantage is a reduction in workload. The time spent physically transporting paper documents from one department to another is saved (and there are many paper-based companies yet). Handover time is also saved. Handover is the time that elapses from when the document is released to when the person responsible for the next activity know that the document awaits its intervention and then really begins to work on it. In both of these cases it is the BPMS that plays the role of “electronic carrier“. Another work that is saved is the one related to coordination. This refers in particular to the time taken to understand what is the next activity to be carried out and the ways to alert the responsible. In fact, in this case it is the BPMS that routes the activity to the relative responsible on the basis of the defined process model and it is always the BPMS that alerts, by email or worklist, the different participants when it is their turn to take the document into work. Another saved time is that to collect all relevant information. In fact, in paper-based organizations the time that people spend collecting all the information is often relevant, as is the back and forward time when you realize that not all the information needed to accomplish an activity is available. In this case it is the BPMS system that allows you to collect and record the information necessary to complete the task before moving on to the next, that thanks to the business rules defined in the BPMS system.
Another important advantage of BPMS is the flexibility that organizations get from using these systems. From what we have said so far it should be clear that BPMS are for operational process management applications, the equivalent of DBMS for data. BPMS are in fact systems that offer a series of generic features on which, you can built the specific software layer of the process-oriented application. BPMS therefore allow you to keep process logic separate from application logic, thus allowing you to intervene on the logic of the process without having to worry about enter into the coded logics in the application and vice versa. The flexibility offered by BPMS also results from the availability of EAI features that, as we have said, allow to integrate and coordinate the other systems of the organization but also external to this, in many cases also making available many standard connectors.
Transparent reading of running processes is another important benefit in adopting BPMS. There are two types of information that BPMS allow to make clear:
- operational information, that relates to the execution of unfinished processes
- historical information, that relates to completed processes
For example, operational information allows you to have an immediate response about the state in which a particular processed document is ,or to highlight what are the tasks in which there are queues, so, where are actions needed.
Historical information, on the other hand, is specifically from the Process Monitoring functions of the BPMS that we talked about earlier. This information is usually aggregated and allows manager to evaluate process performance and adherence to defined rules. For example, they allow to answer questions such as: what is the average cycle time (the average time to complete/close a process from start to finish) the number of cases completed in a given period, or the use of resources, how many cases have violated a particular deadline.
Finally, an important advantage that a BPMS ensures is of course compliance with the rules. In other words, the BPMS ensures that the process is executed exactly in the way it was designed, which is the one that provides greater efficiency to the organization, without any exception. This can be considered a quality benefit: the process always runs consistently, ensuring the same output is always provided with equal input.
This chapter draws many insights fromt he book “Fundamentals of Business Process Management” (2)
Difficulty Introducing a BPMS
But what are the difficulties in introducing a BPMS system? Referring to my own experience, I can say that these are essentially organizational and arising from the lack of a process-oriented organizational culture.
Regarding organizational issues, this comes from the consideration that a BPMS project is not just an IT project, but an organizational project that can sometimes be impacting the entire organization. In fact, by intervening on end-to-end business processes that cross multiple business departments and the way the people operate, can be arise different organizational problems. Coordination: who leads projects involving actions on different departments with different managers? Responsibility: who makes decisions and takes responsibility when business rules or operating modes need to be changed? Nor, the concerns and fears of the operatives who may feel their position in the company threatened by automation or the changes should be overlooked. As well as the transparency on the processes execution may not be welcome or simply worry more than one person, at different business levels, not just the operatives. These problems can be addressed and solved by a strong management commitment and well-studied and implemented change management actions, but this, in my opinion, may not be enough.
And we come to the other problem, more basic, that is a lack of process-oriented organizational culture.
More often, I’ve been involved in BPMS projects just seen as IT projects, and my near-only interlocutor was IT with “convinced” business people that it was time for the ageing of procedures and tools, automation, digital innovation. More often, I’ve been involved in BPMS projects seen just as process redesign projects, and my near-only interlocutor were line managers and operatives, with IT intervening on call about the specific and limited need.
Instead, less often I’ve been involved in bpms projects with multidisciplinary teams, made up of IT and business people who were together in the analysis sessions or when decisions were taken. Even less often I have seen people from different departments participate together, at least those affected by the business processes covered by the project.
This carries two main risks. The first risk is to automate the business process driven by the needs of a single department that have benefits but at the expense of other departments and therefore the entire value-chain of the organization. The other risk is the project failure, which may simply not reach the bpms solution go-live or, when it arrives, its adoption is imposed, by the states of thing, to the operatives, who poorly bear it, because it does not help them in the day-to-day operational work, because it does not do what would have been useful to do as it does not present the functions that would have been necessary , or if it has it, these are not usable in the operative way that would have been necessary.
Conclusions
I would like to conclude this BPMS article, which certainly cannot be exhaustive on the subject, linking myself to what I’ve said in the last paragraph, indicating what I believe are the success factors of a business process change project involving the adoption of a BPMS system.
These are: a strong and convinced executive commitment about the role of business processes to achieve strategic goals, a process owner who has a organization’s processes vision and who has the responsibility and leadership to lead a multidisciplinary team, a strong involvement of IT people, but, in the belief that software systems, such as BPMS systems are, certainly play an important role in these types of projects, but these need to be aligned with organization 's strategic objectives and this can happen only if the management and business process design choices are the driving forces.
Finally, I would leave you with a statement by Paul Harmon on which I agree: “Don’t start with a BPMS project until you are sure that the process you plan to handle with the BPMS application is not already working as you would like once it has been automated by BPMS. In other words, don’t try to consider a redesign project and a BPMS application development project as a one thing. Both projects require their own skills, tools and methodologies. First the process must be redesigned and improved and only later it must be implemented in a BPMS for the execution of the day-to-day” (1).
Note e References
(1) “Business Process Change” IV Edition by Paul Harmon. It’s a comprehensive book about Business Process Management themes. Much of this article is inspired by this book.
(2) “Fundamentals of Business Process Management” II Edition by Marlon Dumas, Marcello La Rosa, Jan Mendling, Hajo A. Reijers. This book is the basis for BPM courses at around 200 universities across the continents. The demand was such that there is a Massive Open Online Course (MOOC) based on the textbook, which brought together over 7,500 participants in its first delivery and over 25,000 in total after several deliveries. And in these Coronavirus complicated day, the publisher, Springer Nature, allow to download a legal, and free copy, available here https://link.springer.com/book/10.1007/978-3-662-56509-4.
(4) From “Business Process Change” IV Edition by Paul Harmon, with some my personal additions
(5) www.sap.com
(6) https://www.win.tue.nl/ieeetfpm/downloads/Process%20Mining%20Manifesto.pdf
Photo by You X Ventures on Unsplash