The BPM world is a divided one with many camps. We have methodology on one side and software on the other. But even the software camp is sub-divided further into those which offer repositories and process analysis capabilities and the other which automate and drive work. Admittedly its a simplistic view of the market but we are entering a tipping point in which some vendors will be left well and truly in the dust.
I came across a customer example recently where they had spent a significant amount of effort in years documenting their processes to create a global process repository, in essence a prime example of a knowledge management system rather than a BPMS. It’s cross-referenced, generates reports, centralized but does nothing more. And on the other hand I’ve come back from PegaWorld where customers are automating and driving efficiency in weeks and months, not years, and it would be true of any other BPMS not just Pega but their new v7 is extremely close in removing this time consuming stage before automation can begin.
And the divide is further complicated when you encounter organizations who have Six Sigma or Lean teams who document processes separately and outwith an incumbent BPA tool. Double the effort, very little benefit.
Of course, a lot of this is a journey and implementing one over the other is very much dependent on the process maturity of the organization itself but I can’t help the feeling that those in the BPA space are slowly being left behind as businesses shift up several gears in a hyper-connected competitive world. I would find it a hard sell to explain to a COO that the return on investment will be over several years and there will be no benefit to be had from automation. In fact, if you were new to the world of process and heard that a competitor took several years just to document their processes but not do anything clever with it you’d either walk away despondent or rubbing your hands in glee at their sloth. But hey, you’ll get a nice static process library out of it that you can click on colored squares.
So, late in the day and we’re almost 6 months down in the year I’m going to make a prediction: BPA players are going to stall over the next couple of years. In fact, the BPA market may just die out completely. There are some that spring to mind that I’ve heard nothing from for a good while, and frankly a BPA acquisition no longer makes any sense in the market now. I think we saw the last of that when TIBCO bought Nimbus.
If you can spend time designing and capturing process artefacts in a repository you might as well do it in something that’s going to allow you to drive that benefit even further. You’re making an investment in the future agility of the business, and while it inevitably boils down to a numbers game (after all, BPA tools are a lot cheaper than BPMS) the fact remains that the man effort to develop a knowledge management system begins to pile up against not driving processes the way they should be; harder, better, faster, stronger.
So, before you decide on documenting vs. automating, keep calm and consider this: are you building a library or are you building agility ?
They are not the same thing.
IT :: redux 
Relevant experience — parts of automation (i.e. executable diagrams) were used as illustrations in the documentation (actually the departmental quality manual) and each human activity had a link to related working instructions.
Thanks,
AS
Didn’t Gartner drop the BPA quadrant?
There was one last year, ARIS came out on top, 12 other players, so there’s still mileage in selling a few more reports on a dying market segment.
They have changed it to Enterprise BPA Marketscape – so BPA alive and kicking in the minds of Gartner
Your prediction for the future of a BPA tools market may be prescient. If an independent market category, justified as a separate dynamic of supply, demand and technology, does not contribute to mission success, then into the dustbin of history I say, along with other relics of Soviet-style management. (Ironically Soviet-style management, the anti-thesis of agility, has often been the norm in Western IT shops.)
The problem is, as you per your allusions, that long planning cycles cannot possibly produce technology artifacts that match the richness of reality, especially when that reality is evolving as fast as it does.
The implications of agile BPM, without BPA as a separate category, are daunting, in at least two dimensions:
(1) Organizational Governance — planning, exemplified by the use of BPA tools, ensures that the organization maintains a fidelity to mission for stockholders or stakeholders — agility and empowerment of edge actors presents a challenge to traditional governance;
(2) Technology Best Practices — BPA tools made it possible to surface and encourage best practices for BPM. In the same way that coding and database design skills have declined, along with democratization of IT, I think it’s quite likely that democratic BPM will product process spaghetti.
Both challenges can be addressed I’m sure. Good analysis and good prediction.
Avoiding process spaghetti is a matter of disciplined business architecture. Just as it was with documenting business processes. The automation tool needs to have the built-in classification and organizational structure to hold and maintain the business architecture that should inherently be done up front in any IT project.
This is a great article about the negative effects of delaying business process automation. Let’s use the sales business process as an example.
If a sales manager wanted to pursue a culture of continuous business process improvement, there could be many potential benefits – improved order entry, less time spent on administrative tasks, and more time spent with potential clients. In fact, the percentage of time spent directly on selling activities with prospects and customers often represents less than 50% of sales capacity.
However, there is some value in documenting business processes. The only issue is that documenting business processes from scratch can take a siginificant amount of time and can lead to frustration. There are almost no resources out there that provide Sales business process flow templates, benchmarks, best practices and improvement opportunities all in one place. However, this online source provides sales business process flow templates, benchmarks, best practices and improvement opportunities for free: http://opsdog.com/improvement/field-sales-support/processmaps
The only place Automate comes before Simplify is in the dictionary
Theo, it can even be worse. You speak about the wasted effort, but there was a study done in Denmark that shows that some public works projects that were planned in advance sometimes were actually executed worse than projects with less planning in advance. This evidence supports the idea that sometimes you can do too much planning, too much design work. What was happening was that by planning too much up front, they committed the project to a course that was then later very hard to change, even when it was apparent there was a better way to do it. This is precisely the agility point you make.
I do not mean to go to the extreme that you should never plan project. Instead, I mean only to say that there exist cases where you should only plan to a certain level, and leave the details to be worked out later!