Business Process Management
Length: 1545 words (4.4 double-spaced pages)
Today however, Business Process Management or BPM, continues to mean many different things depending on the background of the person talking or writing about it. To some business managers, it means creating basic level process models within Departments. To other business managers it means implementing a performance monitoring tool. And to still others, it is a concept and an approach to management. But, to many technical managers, it refers to interfacing applications databases using an Enterprise Application Integration (EAI) tool. The list of “definitions” goes on and on, adding to the confusion both within companies and in the BPM industry.
To make some sense out of the chaos that is overtaking much of BPM, we can offer a simple definition that describes the essence of this critical and powerful movement:
“BPM is a business process based approach to improving business activity and creating automated applications that is supported by a group of new process modelers, application generators, application interface engines, and performance monitoring software. It is based on acceptance of a process based view of the business and the use of process models with clearly visible associated business and technical operation rules.” Dan Morris
If you discuss on BPM, you might come home with your head spinning. One might talk about it strictly as a way to manage business performance, while another talks about it as a technology, and still others make it sound like a new paradigm of business-IT collaboration and alignment. You’re reminded of the fable about the blind men and the elephant
Figure 1. BPM has many faces, making it easy to focus on one and lose sight of the whole.
The answer is that BPM really offers all three of those things. You don’t have to use them all, but you should, in order to get the maximum benefit.
A New Management Discipline
First of all, BPM represents a new management discipline, a new way to look at your business and measure business performance. Historically, companies have been organized around discrete functional units, like sales, engineering, and finance. Each unit manages to its own internal goals, and has used technology to makes its internal processes highly automated and efficient, thanks to enterprise applications like ERP and CRM. But traditional business metrics and goals focused on individual functions – both organizationally and from an IT perspective – fail to measure performance the way a customer or trading partner views it. That is because externally facing business processes cut across functions, departments, and IT systems. Often there is no way even to measure performance end to end.
BPM brings that end-to-end perspective. As a management discipline, BPM emphasizes modeling the business from a cross-functional process perspective, and establishing performance goals from that perspective as well. Years ago, Geary Rummler called this “managing the white space in the organization chart,” and it remains central to the process perspective today.
Process modeling – documenting the steps of the process end-to-end in a way that can be understood across functional units, across geographic units and divisions in the enterprise, and can be analyzed for potential performance improvement – is a key feature of BPM as a new management discipline. Process modeling is inherently a business function, and modeling tools empower the business – not IT – to define the steps, the performance metrics and goals, and the business rules, both in the current (as-is) and any future, improved (to-be) business process.
A New Technology Platform
To some management consultants, BPM starts and ends with modeling, but there’s much more. That’s because BPM also provides a new technology platform that takes the model and metrics defined by the business and turns it into an executable implementation. This platform, called a BPM Suite (BPMS), actually automates the human workflow, integrates data between disparate backend systems, and executes the business rules, controlled by the process model. And while it’s executing the business process, the BPMS continuously records snapshots of data that allow the process to be not only measured end-to-end, but monitored in real time, and corrected easily when the need arises.
The BPMS is not an application. It does not replace your existing enterprise applications. It merely automates the process logic that connects your application systems, databases, and human tasks in the cross-functional business processes that you need to manage and improve. A BPMS provides an integrated suite of components (Figure 2) that provide analytical modeling, executable design, workflow automation, business rule management, application integration, and performance management, also called business activity monitoring, or BAM.
Figure 2. BPM Suites provide an integrated technology platform for modeling, automating, integrating, and monitoring end-to-end business processes.
Definition of terms:
• Process – A cross function association of work activity aggregates that join together to deliver a
specific product, service, or outcome.
• Process Modeling: Discovery and definition of the process (as-is and to-be) using a UI tool.
• Process Engine: This runs the process modeled in UI, allows for management and co-ordination of the process while also providing for effecting dynamic change in the process.
• Workflow – The flow of activity at the organization unit level. At this level, work is normally comprised of task or activity aggregates from multiple processes.
• Reporting and Analysis Tools: Report on process performance based on validation against a pre defined set of metrics.
The BPMS supports a process lifecycle enabling continuous performance improvement. That cycle can begin with modeling, or in some cases, with simply instrumenting backend systems directly and measuring an end-to-end performance baseline. Without implementing anything, process improvements can be proposed “on paper” in a to-be process model, and then converted into an executable implementation in the BPMS design environment. The process design is deployed to the BPMS process engine, which routes the human tasks, executes the business rules, and integrates IT systems across the enterprise.
As each process activity or milestone completes, the process engine records snapshots of instance data in the BAM database. The BPMS’s performance management (BAM) component correlates that data to calculate the end-to-end performance metrics, aggregate them into counts and means and other key performance indicators, and then monitor those KPIs continuously with rules that look for problem conditions, or simply deviations from established norms. When a problem is detected, BAM can flash alerts to a management dashboard or trigger automated remediation using the BPMS.
The process logic executed by the BPMS process engine is essentially an automated flowchart, so changing it is easy. BPMS assumes change. It is designed for change. After changing the process logic, a new version of the process can be deployed without shutting down the system. New business rules can often be deployed without having to redeploy the entire process and related services. By making non-intrusive governance part of change management, BPMS reduces the risk of deploying unapproved or rogue processes. Thus BPMS truly enhances agility, the ability to respond more quickly to changing business demands.
A New Implementation Style
Beyond its merits as an integrated platform for process execution and performance improvement, BPMS also represents a new paradigm of business-IT collaboration, one that is sometimes misunderstood by IT. The essence of this new paradigm is that the executable implementation of the business process – often a mission-critical solution – is directly business-driven. The process model and its associated end-to-end KPIs, both defined by the business, actually drive the process implementation. They don’t merely create a book of business requirements to be interpreted by IT the best they can. The model is actually a part of the executable design.
Obviously, this can be tricky, since business analysts are not professional programmers, and these are mission-critical implementations. Different BPM Suites address this problem in different ways. In some, the model generates skeleton artifacts that are imported into an IT-oriented BPMS design tool. In others – and this approach has additional potential benefits – the executable design environment is used collaboratively by business and IT. In this collaborative paradigm, the model created by the business describes the process “abstractly”, without specifying the technical details of the systems that implement various steps of the process. That technical detail is layered on top of the model by IT, while retaining a business-oriented view into the actual implementation design.
A general characteristic of implementation design in BPMS is that it involves little or no code. We described earlier how the process logic design is entirely graphical, like a flow chart. But the BPMS ideal is that other parts of the implementation design – human task user interfaces and worklists, application integration, and business rules – are also point- click or wizard-driven as well. The code is generated automatically under the covers and deployed to the process engine; it is not edited directly by process designers. This increases agility and allows business and IT to work collaboratively on the process solution