I received the following opinion by email from a Column 2 reader who makes a distinction between automation/workflow and BPM. I invite discussion, and I’ll be adding in my $0.02.
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. Just because the workflow engines now call themselves BPM does not mean that a person is doing BPM when they use them.
When a website or an article about BPM touts the benefits of BPM as being the ability to speed up or automate a business process, reduce the time work is in transit, pinpoint where work is real-time, gather all relevant data on one screen for the worker, increase accountability or allow for the automation of exceptions, I feel that that author just does not ‘get it’. Getting the right thing to the right person (or system) at the right time is workflow; its benefits have long been established (i.e. http://e-workflow.org).
Workflow is powerful and generally has very high payback. One of the weaknesses of workflow is that the process you just automated may not be the best or most efficient process. That is where BPM comes in. 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. If there are places in the BPM process that can be automated while still keeping the focus on gathering the metrics, that is and added bonus. In my mind that constitutes the incorporation of workflow capabilities and benefits into your BPM effort.
I envision a BPM flow initially being only human steps where a person reports back that they have done certain things. In the beginning it would just be additional overhead. As more information is gathered and analyzed this human process is rearranged quickly to remove bottlenecks and inefficiencies. Over time automation of redundant or time consuming steps are added. When automation is added we must be very careful not to make the flow inflexible since the primary goal is to gather data and be flexible, not to automate. If a point of automation is identified but it will add inflexibility, then maybe a tactical workflow application is created and the BPM flow just consumes it as a service. You get the automation but keep the BPM flow as flexible as possible.
Workflow is workflow and BPM is BPM. The trend is to use the workflow engines to do BPM, but they are still distinct entities and are implemented in distinctly different ways. I think this distinction is important because you are not going to get all the benefits promised by the BPM crowed if you spend all your time automating. Automation is good, but BPM + Strategic Automation is better.
work flow is Work flow. [ pinpoint where work is real-time, gather all relevant data ..for the worker ]
As for BPM- I think, we cannot say, just by looking at the results of the process, whether the process that created those results is capable of generating predictable outputs.
Therefore we must understand the process first–and then the he growth imperative is met and becomes sustainable by understanding the forces that drive the process engine. — it is with this understanding that BPM truely comes to being.
anyhoot…just my my 2 cents here :)-
This discussion just highlights the typical way that IT confuses the message. A businessperson despairs at this double talk. He knows what he wants from IT – the ability for the business person to be understood in how he wants his business to run – and guess what that means what his people do. BPM at least goes in right direction in being almost his language “workflow” remains in techie land. The good news is that the movement has evolved to a TOA (Task Orientated Application) yes another TLA! TOA recognizes that business fundamentals do not change. Using proven technologies and working with a relational database a TOA has made conventional programming languages largely redundant for business solutions. A TOA separates business fundamentals from the technology lead delivery process. TOA recognizes there are only a dozen or so task types including links. These tasks definitions have been” codified” as objects/services and liken the environment to a “contained” SOA – result a “generic” solution useable in any part of the business. This is all contained in a data-centric environment supporting software “agility”. This is all built through an intuitive graphical designer and contains rules, state, events, calculations, BPM, workflow, user forms, roles, performers etc all in one contained environment. A TOA delivers real time reporting to address the 3 core business requirements – “compliance, agility and performance management”. The software industry has been long overdue for a technology leap towards maturity a TOA is that leap – workflow and BPM have been stepping stones no more – yes this will create FUD (fear uncertainty and doubt) as both suppliers and businesses absorb the implications
David : Do you have an researchy papers on this “TOA” that you describe as the “This recognition is at the core to a new breed of software – Task Orientated Application “TOA” that has codified tasks in a contained data centric environment resulting a “generic” solution useable in any part of the business.”
http://www.it-analysis.com/enterprise/technology/content.php?cid=8323