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.
Good topic — I certainly love visiting here, commenting and participating in !!
ok ok..back to the board… :)-
Where does one leave off and the other begin, or what is the overlap between them?
Business process Management (BPM) empowers a business analyst to align IT systems with strategic goals by creating well defined enterprise business processes, monitoring their performance, and optimizing for greater operational efficiencies. Each business process is modeled as a set of individual processing tasks. These tasks are typically implemented as services within the enterprise.
The BPM system provides a toolset that allows the business analyst to create process models, using notations such as BPMN, (btw, which is still unclear and there are NO standards set in stone-yet – I am hpoing that bpmi group will get something in order soon as thought leaders in this sphere of emgerging technologies)
…and then and then only –should the enterprise perform automation of business process , or execution of the model, by invoking IT services (SOA ?).
as a sidebar the omg interim specs on SBV/BRS is still in draft mode and hopefully that will set direction on the scemantics of business conversations. I really dont know. There is so much of difference of opionion at this level of the landscape. Some say this and some say that, yet at the end of the day, there will be the need to “Semantize” the very thought process on this mission critical side of the business. Its strategic in nature and certainly the peeps who get it — get it and those who act on it will certainly be an emergent player for bleeding edge practices !!
’nuff said.. !!