Recently in Sandy Kelmsey's blog, she covered the John Hoogland keynote from Ulm on "Change in Control".? Pretty good coverage from Sandy (as usual!) and it sounds like it was an interesting keynote.? But there are a couple of points in it that I take issue with - though I'll allow that since this isn't based on a transcript of Mr. Hoogland's keynote, it could be that something was lost in Sandy's coverage that would alter the picture.? Sandy writes:
He did a closer look at many of the vendors? messages, pointing out the nonsense of much of the marketing speak about how easy and beneficial that BPM is. Agility in that context means that the process can be re-modeled; in fact, that?s often the only point of agility that the BPM vendors allow (although I would argue that integration of rules management creates significantly more agility without process model changes).
I would dispute that BPM vendors are only arguing that only "modeling" can be more agile - they are, in fact, arguing that the execution of the process can be altered with more agility than the present state of affairs in the IT infrastructure with legacy apps and bespoke implementation of processes. In addition, elements of the process can be exposed to process owners (the business) to modify the behavior of the process without requiring a development effort.
He then turns to the fact that process is deployed within IT infrastructure, within the context of these existing applications - and that that, in and of itself, precludes agility.? Well, certainly one can imagine processes being more agile without the heft of these legacy systems or existing infrastructure- but the point isn't "agility" measured against some absolute zero.? The question is - does BPM make you more agile than your current situation, and does that additional agility have sufficient value?? Clearly the answer to both, for most companies, is yes.
Finally he points out:
Other factors also impede agility: the issue of migrating work in progress when the process model changes, including changes to related services. The conclusion: although the vendors make process model changes look easy in the demo, it?s not that easy in reality.
Certainly these factors impede agility.? However - even moreso without a BPMS.? And while these scenarios aren't "easy" they are much easier in a BPMS because they are actually identifiable and measurable.? (As an example, the versioning-related features in Teamworks 7 put issues like this on the front burner and directly address the challenges Mr. Hoogland is presenting).? Still, is it any wonder that software vendors make something look easier in a demonstration than it might be with production data and volumes?
Next, the complexity of process models is attacked.? At some level, processes are only as simple as they are, and no simpler (with apologies to Einstein).? However, having the right process abstractions makes them more accessible to the human mind (and specifically, to the people within the Business who need to understand them).? You have to design in a fair amount of the "knobs and levers" that you want to be able to customize after going to production, and:
This requires an explicit step during the process design to design what parameters have to be able to be changed by the business users on the fly without changing the process model (I am going through exactly this exercise now with a client, and completely agree with his assessment), and ensure that the BPMS is capable of providing those as parameters under direct control of the business.
That makes three of us.? I think in general Mr. Hoogland is trying to inspire the academic and research community to tackle fairly intransigent problems - complexity and expressiveness, agility and in-place upgrades.? He's right to call attention and further effort to these areas - there's no doubt they can improve dramatically over the current state of affairs.? And yet, a good BPMS already offers a clear improvement over the status quo in organizations who are not equipped with a BPMS (with room for improvement still).