I received the following email the other day...

"My colleague and I have been having a running discussion about whether there’s a meaningful distinction between human-centric BPMS and integration-centric BPMS; and, if there is, whether it’s more likely to persist or to erode over time? I argue that that there are many fundamentally human-centric processes being executed in our company every day which have little to do with the ERP screens (etc.), and that these are most effectively managed in a much more agile, decentralized way than with enterprise modeling. My colleague says that 'processes are processes' and that if you model a system-to-system process or a human-to-human process it should all be the same. Since we have an EAI tool, why should we talk to other vendors?"

A General Theory of Process?

This is a healthy debate you're having. I'd like to deconstruct it a bit, though, because the way you've articulated it above is still flying a bit high level. It's hard to argue against a "general theory of process" in principle... it's just that in this case, you and your colleague are overloading the word "process" to mean two things.

Primarily, we need to understand the difference between process patterns and business processes. This is a distinction that industry pundits have inadvertently confused, and those vendors who advocate basing the world around their pipes or execution languages (e.g. an ESB or BPEL or XPDL) have intentionally blurred the differences.

A business process will inevitably follow a process pattern, but a process pattern is not, necessarily, a business process. Integration-centric approaches to BPM often try to confuse you and say, essentially, "you can draw a process pattern using a graphical notation, and you can draw a business process using a graphical notation, therefore executing a system-to-system process pattern must be the same as executing a human-facing business process."

But they are not the same thing. And more importantly, the real payoff isn't in executing a business process, it's in managing a business process. If executing a system-to-system process and managing a business process were the same thing, then all great programmers would be great managers, and all great managers would be great programmers. I mean, I've read all of Jack Welch's books but I don't get the impression he was a great developer...

Why aren't they the same thing? Well, probably 98% of the people in your company do not report to the CIO... they are "in the business." How do they work? What collaborations are required? How much of those collaborations should be explicitly coded, and how much should be left ad hoc? What about reporting, which is key for any human manager to do his or her job? What about tools to understand the decisions humans make? What about visibility into SLA's on activities that are left ad hoc?

Solving for the The 98% Case

Human-centric BPMSs are trying to get to the heart of how to depict and manage the work of those 98%. This is a very different problem than "graphically depicting a workflow and executing it programmatically." Those 98% are there to, essentially, add unstructured value to what they do! Therefore, the job of a BPMS is to (a) help identify the tasks where people don't add value and automate those away and (b) give visibility to the rest of their work so that priorities can be constantly monitored to make sure everyone is working on the right things.

No matter how efficient you get, you will always have 98% of your people "in the business." And the job of management is dealing with those people and making sure they are working on the right things at the right time. Managing a business process involves the coordination and prioritization of many types of activities, some structured, some ad hoc. The execution of the work flow is only a small piece of the puzzle!

Therefore, great "human-facing BPMS" is about centralized visibility in an inherently de-centralized "execution" world. Integration-centric BPMS's take the exact opposite viewpoint. They assume some centralized execution, and then offer very little in the way of reporting, simulation, and optimization. Their view, like rules engine vendors before them, believe the problem is one of automation! Human-centric vendors believe the issue is visibility.

The Methodology is Different

The differences in the path to optimization - the continuous improvement part of the BPM promise - is clear and stark as well. The business-facing vendors are moving more and more into business intelligence realms. I often talk about the goal of human-facing BPMS to be "enhancing the velocity of communication between the business and IT." If we do that then, in the same way as increasing the velocity of the money in an economy actually increases the money supply, we'll be able to increase the value of the process solutions.

Despite the marketing words, take a look at the implementation of optimization capabilities in the products. In order to improve something, you must understand it. And integration-centric tools don't really change the way business people can understand the process... therefore their optimization and improvement tools are simply IT-centric "see it's real easy to change" demoware.

Optimization starts with visibility into process performance. And from there, it requires many technological underpinnings to move the improvements into the real-world process. Look at the entire process-improvement lifecycle, starting with "how is my process meeting it's business objectives" and then move all the way to deploying some changes. You will see vast differences in how the business-centric vs integration-centric products handle this. Is the focus on the business process, or just the development process?

And the Architecture is Different, Too

Want to place a real big pothole along the path to BPM? Just require a specific IT-based technology to be implemented prior to the process being implemented. That's what the integration-centric vendors have done. They require you use their EAI or ESB as the conduit for information. We met with one large integration-centric vendor and they require the linkage between human activities to be their ESB! Agile, huh?

Business-centric approaches must be agnostic to the source. Your legacy environment is too complex to simplistically (and, by the way, profitable for the vendor) require a specific integration scheme. Even so-called "wall-to-wall <name your ERP> shops" aren't, really "wall-to-wall."

And further, the relevant human-centric vendors will focus on external events as much as on integrations, and as much on forms and reports (and the underlying data to power those reports) as to events and integrations. They are three equal pillars of process: events, forms and integrations. You'll typically find the integration-centric platforms to be much more difficult around correlating these events into the business processes.

Conclusion

So here's the punch-line: Business process management will be unified across the enterprise, but it won't be because integration-centric and human-centric approaches converge. It will be because all business process platforms will look like what we call "human-centric BPM" today.

Today's "integration-centric" ERP and EAI platforms will continue to do what they do best: provide a useful conduit for normalizing data across the enterprise and providing a platform for service-enabling the infrastructure. And BPM platforms will be built to consume those services. Will this be a single vendor solution? The best of breed sure won't be, because the audiences are so different.

So it's fairly simple: do you believe you can automate everything a human does or every task they work on? Or do you believe that humans add unique value to given steps?

If it's the former - and this has been the traditional IT approach - then integration-centric is what you'll be more comfortable trying next.

If it's the latter, then you require a business-centric approach that gives:

• new visibility into the tasks, goals, SLAs and priorities of the 98% of the people in the business

• new tools to continually discover the patterns around the decisions the humans make,

• a new process improvement lifecycle to automate more work, continually, over time

The advance of IT doesn't stop with business-centric BPM, but it is the next great step on the journey of embedding technology into the very fabric of the business, so that constant tuning of the automation we use can be done by the business in exactly the same way we constantly tune products, pricing, suppliers and everything else in the business. The paradigm has to change, and the integration-centric approach is no advance at all. It's the same old thing, with a pretty graphical face. Improvement, no doubt, but a step-function advance? Not even close.

For real change, you need a new business-centric approach to technology, what we now call human-centric BPM.

Technorati Tags: BPEL, BPM, BPMS