In the ever evolving and increasingly complex arena of business process management, it sometimes seems that acronyms relating to BPM are multiplying by leaps and bounds, often resulting in more confusion than clarification. Acronyms such as iBPMS, S-BPM (download the book to S-BPM here at Springer Open: link), RW-BPMS (call for papers and workshop in June 2015: link), BP2 along with many others are examples.
An actual effort to visualize, optimize, automate (where possible) and implement business processes, always requires the use of certain core elements to effectively create, maintain and continuously improve within the BPM discipline. Regardless of which technology is being used and the methodology that is being applied – there will always be, at the very heart of things, flow charts, end user forms, variables, system integrations and some sort of reports.
The possibility of visualizing the desired process flow and case sequences is the most basic requirement and the very first step into the world of business process management. Luckily, these core elements are well-covered features in almost all BPM technologies and require the least effort to implement. From open source solutions to enterprise suites, basically all offer some sort of graphical engine that enables a quick and none-technical visual representation of process flows. Many platforms even align to various industry standards such as BPMN, BPEL, WF and others.
Keeping in mind the very basics, normally the second and by far biggest milestone of a BPM initiative will be the creation and maintenance of the end user forms that are dynamically tied to the drafted out process steps. The effort of creating these process forms, which in turn embody most of the end user experience, can represent the use of up to 80% of all resources dedicated to an implementation. There, on the process forms level, the “real” process logic takes shape, where form fields and sub-forms react to data entry, policy validation, simple and complex calculations. As a subset of the form creation one will always encounter in a (semi) parallel manner the definition of the process variables and the resulting data universe. If one were to reduce BPM as a technology and methodology to a bare minimum, the design and implementation of complex and powerful forms would clearly stand out as the most important aspect of later process adaptation and success. Fast, intelligent, adaptive and robust forms are critical for accomplishing the goal of continuously improving and optimizing business processes. Such forms, in some cases can consider themselves to be complete applications, are being created either entirely by code (defying somewhat the very nature of BPM) or leveraged by wizard driven, low code form creation frameworks that produce the active server page source code behind the scenes (such as K2’s Smart Forms, for instance). In analyzing the role forms have to play for a modern and successful BPM solution, it's also important to consider their role in the context of the IoT. Aspects like adaptive, 0 footprint and mobile (app driven) user experiences are being furthered or hindered by the way process forms have been designed and implemented.
Taking a BPM implementation to a true end-to-end level, as it is defined in the ABPMP’s CBOK, a third component is essential–process system integrations. No human centric process reaches its full potential in efficiency and efficacy without such integrations. When considering change and innovation cycles of business software and technologies, one could argue that BPM and ERP are the opposite end of two extremes. While BPM processes are meant to be adjusted periodically, within short periods of time, adapting to volatile market realities, ERP solutions will likely have a much slower frequency of change. From that perspective system integrations within business processes are the most important tools to enhance the BPM end-user experiences by leveraging but yet not duplicating ERP datasets. Besides ERP < -> BPM integrations, there will of course be countless other system interactions that will enhance the impact of an optimized business process, such as cross process and BPM integrations or typical interactions with systems like CRMs, BIs, ECM's, BRE's and more. Some vendors did embark on a system consolidation effort, leading to what Gartner describes as iBPMS, which makes available several of these business applications within a single framework (usually bundling together BPM, ECM, BRE, BI and ESB), thus reducing the need for external system interaction.
Reports or – even more rudimentary – stored, raw process data could be described as the last piece of the “basic” elements of a BPM implementation. Now, while to be sure advanced reporting, BAM, pattern recognition and predictive analytics are powerful features to accompany a process automation, covering the first basic step of making sure that all the process as well as the business (form) data is stored in an automated, uniform, accumulative and (very important) scalable fashion – throughout all implemented business processes – is far more crucial (and more often than not something overlooked) for gaining real process insights and enabling continued improvements. The key ingredients for viable business reports are in part derivatives of the process and form-variable design efforts and in part the understanding of well-defined process metrics.
There are numerous other aspects worth considering when looking at the “art of optimizing and automating business processes”, like identifying a fitting ontology framework for instance, but from our experience at NSI, none will have as much of an impact in determining the successful outcome of BPM projects as will the very basic elements of BPM – flow charting, form designing and variable definition, integration and report building.