Some of you bright eyed people will have noticed that Lombardi announced a new process modeling environment today called “Blueprint”. As you will no doubt surmise from my review Put to the Test: Lombardi Takes BPM Mainstream on Intelligent Enterprise, I have known about it for some time. I find it a really interesting development that I think will put a rocket under some of the current process modeling vendors.
An there in lies a set of perspectives that I have been holding off writing about for some time. I have for a long time felt a certain degree of unease around process modeling approaches that require a large amount of effort up front before any real value is delivered. In the 90s this took the form of IDEF0 modeling and SADT/SSADM style approaches.
I was involved in implementing and assessing these approaches and it always worried me how much work they took … and how quickly any particular repository got out of date. In one study I undertook, a rather large, well known British Oil company had decided to build a “process reference” model for their operations in Europe. That was a team of around 100 consultants (from PwC and Oasis) for over a year (work out the budget) to create a reference book of IDEF0 models – the users complained of measuring output … and how incomprehensible the models were … and how they had to develop a set of best practices to help people understand them (like putting all the ICOMs inside role oriented boxes to show who was responsible for undertaking the work). For anyone who is interested, this study was published as part of Process Product Watch (a set of modeling and workflow reviews that I published through the 90s).
I seem to remember the statistic of 6 months being how often you should revisit any part of the business before the models contained in the repository was out of date (and that was a number quoted to me by one of the original brains behind SSADM in 1996). If anything the problems have got worse – the pace of business change and evolution has only accelerated since then.
And that brings us to the modern day. Where we have BP-oriented modeling tools talking about BPM and trying to convince everyone that it is just a matter of a quick export to your favorite BPMS.
Sandy Kemsley, in her excellent blog series from the IDS Scheer event (I was invited but unfortunately could not travel this week), points to a fundamental problem I see in many process modeling repository-oriented tools.
“This really came around to the issue of how to get those process models into an execution engine, or if anyone is really doing it at all. Naidoo said that what was moving from ARIS to the execution engine was a “process outline”, which then required some amount of work to hook it up to the BPMS engine (as expected), and that the main value is not in the transfer itself — which could be readily recreated in the BPMS designer directly — but in engaging the business in the entire process design cycle. This, then, is what I suspected: that most people really are redrawing the process models in the BPMS designer, adding who knows how many translation errors along the way, because there is insufficient value to bother with the direct integration. This is not unique to ARIS; I saw the same thing at the Proforma user conference last year.”
And Bruce Silver (who was also at the IDS Process World event) in his posting Almost Dead from Process World talked about two different classes of ARIS user – a group of business people developing a rigorous repository of stuff (about how they do business and the systems/data etc that fit into that); and a second group which are doing BPMS style things – automating their processes, etc.
This is an interesting observation that I think gets to the heart of the disparate camps we see at BPM conferences – where one group is all about the people/soft side and driving organizational transformation; the other is concerned with automating processes using BPM Suites and workflow tools to drive cost and errors out of the process, all the while reducing cycle time.
All very cozy, but at the same time completely at odds with what I think is likely to happen going forward. I have for some time complained that the fidelity is just not yet available when you move models from the repository style tool to the BPMS Suite (if we see widespread adoption of BPDM then this problem will be significantly redressed). Add to this the fact that to make the repository style approach really useful means engaging in a certain degree of “analysis paralysis” as users flounder about wondering where to stop. Part of the problem here is to do with how we represent processes (while flow diagrams are familiar they do not really tell the whole story).
The point is that what most people do is not the best practice. After getting stuck in a rut for while (modeling everything in sight), management is starting to loose patience with the current effort and the team is now being pressured to get some value back out. So perhaps they implement what they have on a BPM Suite. Only problem is that is is often pretty much the same as the original (mess). So now we have an automated mess. After a year or two, people suddenly realize there is another way of looking at the process and end-up throwing out their earlier endeavor, re-implementing a radically improved process that reflects their new-found wisdom. But along the way they have wasted several man-years of effort and untold lost opportunity space.
And this is what concerns me – the amount of time and effort that is needed to get to the point where value is delivered via the comprehensive rspository style approach. Which in a way, brings me full circle to the Lombardi announcement today. An easy to use modeling environment, delivered on demand using a SaaS model and supporting wiki-style collaboration between the protagonists is definitely a much quicker way of getting to value. [Note to Sandy – I too have been using the term Process Wiki for a couple of years … but I think Blueprint has a ways to go yet before we get to a Process Wiki]. Using this sort of modeling approach it becomes possible to quickly outline the process, flip it over into an execution environment (TeamWorks or some other that supports BPDM) and you are away laughing.
If deployed widely, it will enable a wide variety of users to engage in process modeling (something that is denied to them with virtually all other current approaches). Blueprint relies on the simplicity of the outlining approach and the ease of deployment.