Two: I clearly have a ‘paper’ or content focus and so has the Papyrus Platform as an integral part — the major distinction to all other process oriented solutions.

Three: I have been saying to all ACM proponents that there is not much wrong to call what we do BPM and it will most probably be considered that anyway.

Four: Adaptive process IS NOT JUST about ad-hoc, unstructured and unregulated work. It is about the USER being able to create the process as structured or unstructured as necessary and keep modifying the instance or the template as a normal part of processing. Should some process be the way it is needed, it will simply stop being changed. The main point is who models and when. Not unstructured versus structured. Yes, we do BPMN also because people just can not perceive process right now without it and for some simple flows it is usable. But it is also a limitation that must not be mandatory. Some processes looked at throught the BPMN lense are just an assembly of tasks, controlled by states,events and rules.

Five: I see the distinction between orthodox BPM and ADAPTIVE process as linked to the management paradigm. Executives either want to manage old-style, command and control or the see the empowered emplyoee as the driver of innovation. More here: http://isismjpucher.wordpress.com/2010/05/15/the-knowledge-between-your-ears/

Whether this can be extended to high volume back office processing, where BPM has provided the greatest benefit over the last 10-20 years (choose your period depending on your definition and history book), I’m less sure. In this environment, process sequence is one dimension – the relationship between resources and volumes and, in particular, case prioritisation is the other. Are these variables (which drive what each individual should work on next) also supposed to be adaptive? Easy to say, just possible to conceive …. has anyone engineered it yet?

Another potential challenge is that in the ‘paper factory’ there will always be some rules. In a mortgage process you simply cannot do a title search without first knowing the property address; you may well not be allowed to order a valuation until you’ve checked that the individual is employed (because valuations cost money); and well-established metrics may show that whilst individuals may wish to experiment with [c,a,b] versus [a,b,c], overall efficiency is clearly maximised through a division of labour whereby some do [a,a,a], others [b,b,b] and still others [c,c,c].

My hunch is that adaptive processing will eventually become popular in this sort of business environment as a hybrid model of Adaptive BPM (for want of a better term), combining some very clear and prescriptive rules – maybe still using flowcharts! – with some process areas that offer workers choices that will be measured, fed back … and perhaps eventually baked in.

I think what you are doing is BPM, btw, in that it is technology that models, executes and improves processes – the difference lies in the type of modelling (more individual rules, fewer sequential flows) and perhaps improvement (where ‘adaptive’ does suggest a degree of automation or at least end user direction, rather than business analysis support per a traditional BPMS). I’m not sure whether you’d view that opinion as a good or a bad thing, mind you….

Anyway, good luck!

ARIS and all other flow-paradigmes are old-style orthodox BPM. Reporting, logging and comparing KPI data has nothing to do with being adaptive one way or the other. I am glad you mention that all-out BPM actually reduces the agility of a business. Exactly my words for the last ten years. So is there anything good about BPM as a concept? Yes, there is. It defines process owners and their goals and thus focuses on outcomes and not on structural organization. Is there a need to work according to flowcharts towards those goals? Absolutely not. Can technology empower the actors to be more efficient? Absolutely. Can technology provide up and down the line transparency to actually make BPM work? I would not know another way!

Till today, when one does not offer a flowcharting tool it is clearly not considered BPM. We have offered the state/event driven and tool/material controlled processes mostly focused on content with Papyrus since 2001: That’s not BPM I was told. It was not yet Design-by-Doing (adaptive in Jim Sinurs diction) then, but processes could dynamically changed at runtime. We added to that user-definable business rules in 2003, but no, that was not BPM either, but clearly it was Design-by-Doing. In 2007 we introduced the User-Trained Agent that would kick off activities based on a machine learning principle and that is Design-by-Doing ALL THE WAY. Nope, we were told by analysts and customers – no flowcharts means it is not BPM.

Question: As soon as you empower the process owner and his team to execute any way they feel works and you get the most efficient execution, does anyone care if they use a flowchart or if it is called workflow, BPM or collaboration? Absolutely not. BPM is mostly bureauracy today and linked to inhumane Measure-to-Manage management paradigmes such as SixSigma and Balanced Score Card. If you focus on errors and numbers that’s what you get. No more. By what means would that improve outcomes for people – employees and customers? Well, it doesn’t.

So why is everyone trying to expand BPM now? They do not want to admit that possibly BPM is not the final wisdom that it was proposed to be for so long. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit to have been wrong. I see history repeating itself. When we introcuded dynmic document formatting in 1994 a customer got up really upset: “Why are you doing this? Forms worked fine and as soon as our competitors will pick this up, we will have to do it as well!” The same is happening now. I had someone ask exactly the same: “Why are you rocking the BPM boat? Once someone starts to do Adaptive Processes, we will have to follow along and all the money we spent on BPM will be wasted.” Sorry, guys – I told you so for a long time. Now the time has come.

I for my part don’t really care whether the solutions I offer with the Papyrus Platform are considered BPM, ACM, ECM, CRM, BI or the most powerful application development platform available. And it fact it should not matter to my customers either.

ARIS is of course far from proprietary to SAP, and is used by others including Oracle BPM in 11g and, presumably, by its new owner, Software AG, too. Possibly a good example of a ‘BPM-enabling’ technology.

One other comment, having read your blog. You may be interested to know that one of the ARIS modules does something similar to your Business State Machine. One can define KPI values in it, and It extracts log data from the target system and provides graphical reporting based on bringing the KPIs together with the log data. It’s been a while since I last used it, but that’s my recollection.

btw I have no commercial links with Software AG/IDS-Scheer – I just thought this might be interesting. There may well be other products from other vendors that do similar things.

I’m glad you raised the “workflow is the old stuff we don’t do any more” perspective, Keith. I nearly went down that road in the original post, deciding against it for brevity’s sake. What I think is really interesting, when one uses integrated ‘modeling, simulation and analysis’ as the differentiator between BPM and workflow, is that in 2010, well over 10 years since ‘pure-play’ BPM products arrived on the market*, it seems to me that products that have either no, or only nominal, ‘modeling, simulation and analysis’ functionality continue to prosper and, arguably, even to dominate the BPM/workflow market.

So, far from disrespecting workflow products, this definition arguably challenges the BPM vendors (and, perhaps even more importantly, the whole concept of BPM) – what is lacking in the BPM story (benefits? available functionality?) that has prevented BPM from wholly replacing workflow over this extended period?

Is it ultimately customer-driven? The benefits of process execution are easily fitted into a 12-24 month return on investment, whilst those of process improvement must more or less by definition occur over a longer time-frame. So if a workflow vendor can demonstrate even a small additional saving or benefit in relation to execution (eg easier integration with core systems; built-in document management functionality; more flexible work management) this can easily outweigh – within the terms of a typical customer’s business case – the benefits of a more comprehensive modelling/simulation offering.

The noughties have seen many truly enterprise-scope workflow roll-outs, and the results have tended to highlight the outcomes of this type of thinking. Positives include great productivity and customer service improvements, with negatives being frustration at both the lack of change in the way that processes are managed/ improved post-go-live (relative to the situation with paper processes) and an actual decrease in business agility that has taken place (ditto). As a result I think the next decade will see increasing demand from customers themselves for (true) BPM.

This is why I raised the topic and gave it the title of ‘Renewing BPM for the coming decade’. The difference between process execution and management/improvement is a real, live issue in the market and there are years of development left in meeting that demand. And, of course, there’s a whole stack of upside for the customers, vendors and integrators who get it right.

* As evidence for that dating, beyond my own memory, Metastorm’s web site states ‘1996 – Metastorm incorporates to become one of the first pure-play BPM vendors.’ My emphasis.

I think BPM did not come into use until 2001, but otherwise I agree it was largely a repositioning of existing technologies.

Bullet one of your definition uses “workflow” without defining that. You seem to align with the “workflow is the old stuff we don’t do any more” definition which vendors pushed 5 years ago. Many workflow products had modeling, simulation and analysis. You point is that BPM requires these, which I agree with, but I don’t think it is clear that products without these are necessarily “workflow”.

I have always stressed that BPM is a management practice, while BPM technology, or a BPM Suite might be a product which supports, but is not necessarily required for BPM. This would mean that I disagree with your fourth bullet point.

The definition from WfMC was:

Business Process Management – The practice of developing, running, performance measuring, and simulating Business Processes to effect the continued improvement of those processes. Business Process Management is concerned with the lifecycle of the Process Definition.

In absence of a widely agreed upon definition, any work to get an agreement would be welcome.