Over the christmas break, I came across a software architecture podcast that discussed the concept of “Business Process Management”. Making BPM a topic in the context of software architecture raised my curiosity and should have warned me upfront. Two invited experts started their discussion defining BPM. The results were extraordinary but predictable given the technical nature of this podcast series. Both questioned the term “management” as an integral part of BPM. They defined BPM rather as a lifecycle of business processes and considered “management” misleading and confusing.
Well, this certainly is something that I (and most business analysts) could not subscribe to, but why is that? What makes BPM what the words say – a management task? When you look it up in the scholars’ literature, it is defined as a “management practice to align business processes to corporate strategy, to analyze, optimize and implement best-in-class processes”. Though, this definition makes it even more complex: managing your business by managing your processes?
Well indeed, organizations that have successfully completed single BPM projects realize that they need a more structured approach to standardize BPM activities across projects and across stakeholders.
This need motivates BPM as a process in its own, that defines guidelines and policies on how BPM initiatives shall be performed. Thus, the “M” in BPM directly leads to process governance.
The lifecycle of business processes following the four phases of strategy, design, implementation, and controlling – as mentioned in the podcast – actually is such a governance process, though on a very high level.
A more illustrative example of BPM governance is the “release cycle management” process. To avoid an uncontrolled growth of process models, most organizations install a reviewing process. It starts with the process analyst designing a process, continues with a process reviewer assessing the model with respect to formal compliance to modeling conventions and with respect to the content of the model. Before the new process model is published and trained to the organization’s staff, the process owner needs to approve (or reject) it for final release. This approach includes four roles with different views on the same business process models.
BPM processes such as “release cycle management” are based on organizational rules and regulations. With increasing size of an organization, BPM processes become too complex to be performed manually. The pure number of stakeholders, their responsibilities, iterations, changes, etc. makes effectively enforcing rules and policies an enormous challenge.
ARIS Process Governance responds to this need for automated enforcement of process governance with a model-based design environment to define governance processes, a workflow engine that executes governance processes as defined in the model, and a performance management tool to monitor and analyze operational governance data. All three phases share the same model repository that maintains both governance process models and business process models:
- Definition: Following some specific modeling conventions, governance processes can be designed as an event-driven process chain including tasks, IT services, roles, screens, data flows and notifications. This allows for business analyst to prepare their governance processes in the familiar EPC notation.
- Deployment: With a specific transformation mechanism, EPC diagrams get transformed into BPMN models to deploy them on the BPMN workflow engine. Such a model-driven implementation allows for realizing changes within a short period of time in the EPC diagram without any programming skills.
- Execution: Executing a governance process with ARIS Process Governance allows for generating BPM tasks to be performed by specific stakeholders, notifying stakeholders on process model changes or new BPM tasks, automating ARIS functionality and integrating third-party applications.
- Monitoring: The process board gives all BPM stakeholders an overview of their pending tasks. In a separate view, project managers can follow the current status of all BPM processes and monitor them with ARIS PPM as known for operational business processes.
The monitoring part completes the picture of BPM as a management practice with all managerial actions (“planning, organizing, staffing, leading and controlling”) you usually find in your business textbook. As most management tasks, BPM processes remain very human-intensive with heaps of human interactions. This makes it a knowledge-intensive, creative and entrepreneurial but also a risky challenge. Automating these BPM governance to a reasonable extent reduces the risk of pure manual BPM and makes BPM governance the supreme form of BPM project management.
The savvy reader may have noticed that governance processes are subject to the same lifecycle as operational processes. Strictly speaking, this would lead to another managerial level, the management of governance processes. As this is a little bit too much of management, I better close for now and leave this question open for further discussion.
