Another of the vendor sessions, and I’m sitting in on the BEA session, at least for Jesper’s half of the talk (I’m still torn on whether to stick around for the second half or scoot over to the Savvion user panel).
BEA is really realigning their message to put equal weight on their Enterprise 2.0 platform (which I covered extensively at their conference earlier this year) along with BPM and SOA.
Jesper started with a bit of a BPM market review, somewhat unnecessary given the information from Gartner that we’ve seen so far today, but quickly moved on to the most common challenges that they’ve determined based on a recent survey with their customers: inflated expectations (which relates directly to the position of BPMS as shown on the BPM hype cycle that Janelle Hill showed in the previous talk), organizational barriers, deployment complexity, user acceptance, and lack of skilled business analysts (to which Hill also referred).
He covered some best practices such as building a centre of excellence and using an iterative/agile methods, and discussed a matrix for prioritizing BPM implementation projects based on the cross product of their complexity and their process impact: start with the simplest process that has the least impact, then move along the direction of increasing process impact, then return to low-impact, high-complexity processes before finishing with high complexity and process impact. He showed a sample of a prioritization matrix with various processes for an organization plotted out by complexity and impact, which would offer a good guideline for planning the implementation of BPM projects.
In their lifecycle assessment survey (I believe that this is the one that they have online on their website), they’ve seen that there’s a measurable impact of SOA on the success and speed of BPM projects. This isn’t surprising, but it’s good to see some empirical data to back it up.
As a follow-on from some of the earlier comments from today, Jesper also sees that the future of BPM will move beyond the standard type of transactional flows that are common today and into more collaborative interactions and decision-making that involve ambiguity and require tacit knowledge, often as part of the same processes. That goes back to the same message that the people in the process are becoming more of the focus for BPM; it’s my opinion that we’ve done so much in automating tasks and streamlining transactional processes that a lot of the heavy lifting has been done here, and the new and interesting stuff is going to be turning back to look at the messy human-facing processes that haven’t been touched by BPM yet.
I did drop over for the Savvion panel in the second half of this session, but it was fairly unstructured questions from the audience so difficult to blog although interesting to attend.