Impressive sounding title to this article on BPM.com by Terry Schurter.
Terry gives a good background to bring new arrivals to the BPM market up-to-speed, and then dives into dividing the commercial BPM market into 4 segments:
1) Executable BPM software:
Software that is executable, meaning it moves data (in one of a number of forms) from interaction to interaction (between any combination of systems and people).
2) Non-Executable BPM software:
Software that is used to plan, manage, architect, analyze and visualize ?processes.?
3) Technical Consulting services:
Services that design, manage, implement and maintain executable BPM software and/or other software to achieve a similar result.
4) Process Consulting services:
Services that help organizations address problems from a ?process? perspective; deal with the change requirements associated with ?business? changes, and lead improvement initiatives.
Hard to argue with this part.? BP3, for example, provides services to the latter two categories, because we feel there is a gap in offerings in the BPM space that address both technical consulting and process consulting adequately, with appropriate experts in both (there are services companies that are experts in one and novices in the other).
However, I found the overall tone of the article to be a bit negative- perhaps to counteract vendor "hype" which he refers to at several points in the article.? For example, he posits that BPM does not address human processes well.? But of course, when making such a statement, one has to follow with "as compared to what?" - because the bar that any software should be judged against is not an abstract concept of perfection, but rather that of its peers.? If, for example, BPM executable software suites represent human processes 50% to 100% (picking arbitrary range here) better than existing application integration software, that may well be "good enough" for now. In another part of the article, he points out that executable BPM vendors don't address more dynamic/ad-hoc processes.? I would agree that they don't address these well -but in my experience the factor holding us back from addressing these processes is the creativity of the process author (consultant, in many cases), rather than the underlying technology.? Technical consultants want to see order out of a chaotic process and try to fit the square peg in a round hole.? Process consultants don't understand how they can parameterize the underlying software to make it more dynamic and responsive to the individual user's personal process.? Both types of personalities need to be experts in their software of choice, and creative with their application thereof.
At one point in the article, Mr. Schurter mentions that BPM vendors have been frustrated by the space not "popping" as they hope or expect.? But I didn't feel like he directly addressed why.? My personal opinion:? First, any software that is focused on real ROI, and delivering it, is training customers to not buy all at once, but to buy piecemeal and prove the value.? Second, BPM requires an intersection of skillsets that are hard to come by in one person's body.? So what's the good news?? I don't believe there will be a popping of a BPM bubble either.? In several other spaces, the market grew faster than the vendors' ability to mature and provide quality software to a bigger and broader set of audience needs.? The vendors ossified around narrower technology offerings faster, and sold them like hot-cakes. But when it came time to extend and branch out, it wasn't in their DNA, and the growth stopped or stalled dramatically.? I believe BPM's growth rate has afforded vendors the time to invest in new features, and mature their platforms, considerably.? The growth rate is also giving the market time to provide the skilled practitioners needed to deliver these solutions.
Mr. Schurter also offers several lessons learned:
1.? The Need for Individual Process Orchestration
2.? Workflow Queues are Extremely Limited
3.? The need to "Capture" Reality
4.? Unstructured or Free-forming Processes
Its hard to argue with these on the face of it, but I found myself looking for more prescriptive solutions rather than just acknowlegment of the problems (lessons).? The part I wanted to learn from the article was how he suggests to address these issues.? For example in discussing alternates to workflow queues, he says the "means by which this is accomplished is highly variable", but I was looking for examples:? RSS feeds?? simpler integration to email?? How does one provide the work to the right people without introducing new work?? How do you measure without interfering? For Capturing Reality and Free-forming processes, Terry rightly points out there are vendors scratching the surface of these ideas now.? But Unstructured processes isn't really a technical problem (as I pointed out earlier) - it is much more a problem of creativity of representation.
Maybe to sum it up, the state of the union for BPM in 2009 has as many questions as answers.? My take, however:? the ROI from BPM projects is real, and companies are going to keep investing in BPM as a result.? Nothing in 2008, or early returns from 2009, convinces me otherwise.