This is the first installment of a monthly column. My focus is software technology dedicated to automating, integrating, and managing business processes, the building blocks of so-called business process management systems (BPMS). I readily admit that within the BPM community there is a contingent that believes BPM has little to do with software, that it’s really a new way of thinking about the business. And I even understand that to a business or IT manager long frustrated by the agility and efficiency barriers posed by their traditional organizational stovepipes, simply moving to a cross-functional process perspective for analysis and performance management is revolutionary in itself. But if you’re using BPM just as a descriptive framework for your business, you’re not really getting the full benefit. In fact, I’ll go further. If you aren’t using a BPMS, you’re not really doing BPM.
The distinction between true BPM and what I would call not-quite-BPM shows up most clearly in process modeling. There are all kinds of process models and modeling tools. Some are purely descriptive and analytical. They let you capture in some graphical notation the as-is process, alter it diagrammatically to a variety of to-be alternatives, and analyze them through simulation to optimize key performance indicators. The optimum agreed-upon model has great value. It documents the new business process, and defines process-oriented performance metrics. But at this point it’s just a description, a diagram. It’s not “making it happen.”
With BPMS, the descriptive or analytical model is just the starting point. It is converted, using standard languages and tools, into an executable model that actually ties together the systems, people, and data that comprise the business process, and generates the events needed to calculate the key performance indicators. The model is not just a diagram. It actually executes, integrates, and monitors the process.
Why is that important? Agility, for one thing. Central to the BPMS idea is that agility depends on separating process logic, which should be easy to change, from functional business logic, usually embedded in business systems, which are difficult and expensive to change. In fact, the process logic is just the executable model. Changing it is as simply as re-drawing the flow in the executable process diagram. It doesn’t even require programming.
Another benefit is integration. Integration middleware has evolved in the past few years from expensive, proprietary, hard-to-use technology to standards-based, increasingly commoditized, and much-easier-to-use components. Today, middleware components called integration adapters can “wrap” business systems, even legacy systems, and allow them to exchange data and events through a standards-based communications fabric called an enterprise service bus. But by itself, integration middleware doesn’t provide a good framework for managing when System A should update System B, or record this interaction for use in KPI metrics. Those functions, which require tracking the state of the end-to-end flow, are part of the process logic defined in an executable process model. The process model assumes such integration infrastructure is in place, allowing it to execute process steps on any connected business system.
A third benefit is human workflow. The not-quite-BPM crowd likes to say “business processes are about people, not systems.” That’s because you can organize human tasks without automating anything. But businesses have long known that for many types of human activity, workflow automation provides huge benefits in increased productivity, cycle time improvement, and compliance with regulations and best practices. BPMS puts human tasks and integration activities on a common footing. Both are represented by steps in the process model, automated by a process engine, and monitored for performance management.
These basic elements – a design tool for building executable models, a runtime engine that executes the model, and a performance management framework for process tracking and reporting – are the essence of a BPMS. Although BPMS offerings vary widely – differing in system architecture, special features, emphasis on integration vs human workflow – they all contain these three essential elements. Where cross-functional “process thinking” is the end result of not-quite-BPM, BPMS translates that thinking into a real business solution.
Without it, you’re not really doing BPM.
