A couple of weeks ago, I posted a letter from a reader who asked the question “Is Automation BPM?” Peter Dawson and David Chassels both chimed in with their comments, and I want to add my thoughts. Excepts from the original letter:
I have a hard time referring to it as BPM when a person simply automates a business process. To me that is workflow. Granted, we have powerful stand-alone workflow engines now that allow a workflow to route work between more people and systems than ever before, but it is still workflow.
If you have a workflow process that is less focused on automating work and more focused on gathering data about a process for later analysis, then you have entered the realm of BPM.
I disagree. I started in the old workflow world: for the past 18 years, I’ve been focussed on processes that usually have a large human-facing component. I started with traditional workflow products that only provided person-to-person routing of scanned documents, which is about as old fashioned as it gets in the workflow world. Since I worked for most of that time providing services to the customers of these systems, I did a lot of automation and integration work from scratch because that functionality just didn’t exist in the workflow systems. Want an automated function in your 1993 IBM ImagePlus system to escalate items that have been sitting in a queue too long? No problem, we’d write a daemon that would cycle through the work in a queue and push specific items to an exception queue. Want to integrate your 1991 Keyfile system with an Oracle database application? Give us a few weeks, we’d write a front-end application that integrated the two systems at the presentation layer by making API calls to each system. Want to have some process reports from your 1994 FileNet Visual WorkFlo system? Okay, we’d write a batch process to interrogate the database history logs each night, extract the process-related data and print some reports.
The point is, the systems as provided by the vendors had no automation and no integration: they were concerned only with the flow of work from one queue to another. Work. Flow. Workflow. Everything else — integration, automation, process monitoring and governance — was custom built. I could, in fact, make the argument that what we did as services firms was to turn vendors’ workflow products into business process management systems.
From a semantic standpoint, the term “workflow” has been absorbed into most definitions of “BPM” (except, perhaps, those definitions created by ESB vendors who prefer an integration-focussed definition). Even the old-style workflow that I describe above — just routing from one person to another — is a part of BPM, even though a system that only provides that level of functionality would not compete very well in the broad BPM marketplace. The fact is, however, that almost every product in the BPM space has a set of functions that doesn’t quite overlap with anyone others, and doesn’t overlap at all with some other products that are also called BPM. Gartner published a report on BPMS selection criteria a few months back that listed 10 major areas of functionality, but there are many products in the BPM space that don’t have one or more of those functions covered. The problem, as I’ve written about before, is that the term is too broad, and was a bit of an artificial creation on the part of the analysts, who took workflow, EAI, and anything else remotely related to process and called it all BPM.
To get back to my rebuttal, then, I believe that as soon as you add integration and automation capabilities to human-facing workflow, you’ve got BPM (as opposed to just being able to call it BPM because workflow is now defined as a subset of BPM). From the other side of the house, the same can be said about adding human-facing functionality to EAI to create BPM.