I had a very interesting interaction with a global VP of BPM of BPM for a major vendor. The encounter went like this…
VP on behalf of vendor demonstrates BPM tools to potential client. Everyone oohs and ahhs at the impressive presentation, graphics, and overall possibilities of BPM. The vendor product looks impressive, it works, and actually has reasonable (runtime) performance.
Then I ask the VP “how many processes can this client create in a year?”. After all, creating a BPM workflow / process is relatively quick and easy. In theory a couple of days to create it, another week to test it and deploy it. Maybe a mid-sized organization should be able to generate 26 processes per year per person assigned to BPM.
The VP responded, “7”. “Seven”, I remarked, “why so few?” He explained first of all the BPM processes won’t have all their steps exposed (at all or at the right level of granularity). This turns almost every BPM creation into an integration project (and explains why many BPM tools come with a large number of adapters and other integration components – because they have to struggle to get to the process steps or data needed for them).
Then he added that few businesses actually have their processes mapped out. So the managers must get together with a business process modeler, model the process, run it through a few senior managers who revise it, send it back down where they adjust it, and finally get the process approved. Then when they deploy it they find out that how the managers think things are working is not exactly how they ARE working…and it goes through a revision to reality. Naturally the whole thing can take a few months.
So what has happened? I see BPM as having divided into two separate directions, with most tools focused on one side or the other. The first are very pure business driven Business Process Modeling and Execution tools. These tools and projects are driven by the business with limited IT involvement, and while they directly solve business problems they are limited in their ability to do so due to IT not offering the access to the IT systems/services performing the business steps.
The second are Business Process Automation tools and features, some of which have become part of a number of Enterprise Service Bus products (others which are tightly integrated with ESB’s and architecturally a close layer above). In many cases the ESB logic of specific integrations has been morphing into partial (and sometimes complete) business process automation routines. And the ESB’s themselves often offer a fully visual drag-and-drop drag-and-connect modeling-like environment for creating them.
As I note to the confusion of my colleagues, a BPM process may be exposed as a service and be composed of services. It’s activating event may be a service request, and it’s terminating action may be to activate a service.
There may be no differentiating factor between the approaches from the tool standpoint (and both IBM and Software AG have been busy buying both the higher business approach tools and the lower BPM automation tools – with roadmaps for merging them together), but there is a common differentiator from the IT standpoint…
When processes are particularly long running (days or longer) and/or include stops for human input (or interaction or approval), these are typically the business oriented BPM processes. When the processes are short running (seconds to hours) and/or don’t normally require human interaction (except in case of an exception), these are typically business process automation routines.
Business Process Automation offers significant possibilities to IT architecture and inter-system and component interaction designs and should directly be incorporated into the Enterprise Architecture and Enterprise Integration Layer (or tightly coupled to it right above).
Business Process Modeling and Execution (execution of the model) has shown less success as an enterprise APPROACH and should be targeted at specific business problems where it will directly bring it’s ROI.