TUCON: Process Plans using iProcess Conductor
The last session of the day — and likely the last one of the conference for me, since I think that the engineering roundtables tomorrow morning are targeted at customers — was Enrique Goizueta of TIBCO discussing a "Lego approach" to creating business processes: dynamic BPM using the iProcess Conductor. Bruce Silver raved about the Conductor after seeing it at the solutions showcase on Tuesday, and it seems to have been a well-kept secret from those of us who watch the BPM space.
Goizueta started by discussing complex processes such as the cross-selling bundling processes seen in telecommunications and financial services, or claims management that may include both property damage and bodily injury exposures. In many cases, there are too many alternatives to realistically model all process possibilities explicitly, or the process is dynamic and specific instances may change during execution. The key is to identify reusable parts of the process and publish them as discrete processes in a process library, then mix them together at runtime as required for the specific situation. Each of these is a fully-functional, self-contained process, but the Conductor packages up a set of these at runtime and manages them as a "plan", presenting this package as a Gantt chart similar to a project plan. As with tasks in a project plan, you can set dependencies within a plan in Conductor, e.g., not starting one process until another is completed, or starting one process two weeks after another process starts. The iProcess engine still executes the processes, but Conductor is a layer above that to allow you to manage and monitor all the processes together in order to manage dependencies and identify the critical path across the set of processes.
This is very cool just as it is, but the Conductor also allows you to change a plan while it’s executing, adding and canceling processes on the fly.
He gave us a demo of Conductor for auto insurance claims management, where both vehicle damage and personal injury claims have been made, and these must be completed before the liability claim can be started processing.
For processes that always run together as single instances, such as a loss adjustment report followed by a vehicle repair claim, I’m not sure why you would represent these as separate processes that are put in the plan as end-to-end rather than subprocesses called by a single process, but there are other parts of this where the benefit of using Conductor is more clear, such as the ability to dynamically add a second liability claim a week into the process.
As Bruce pointed out, this is really case management, but it’s pretty nice case management. SLAs and critical paths can now be managed across the entire plan as well as for each individual process within it, and there’s lots of examples of complex processes that could benefit from this type of dynamic BPM.
Tonight we’re all off to the Exploratorium, where TIBCO is hosting a private party for us to check out the fun and interactive science exhibits. I’m flying back to Toronto tomorrow, which might give me a few hours on the flight to finish up some other blog posts that I’ve been working on, and watch for my coverage of SAPPHIRE next week from Orlando.
Also tagged enrique goizueta, iprocess conductor
There are three key leadership roles in any BPM project, immediately below the business executive sponsor: the project manager, the business process analyst/architect, and the systems architect. I have to say this is true of any business-facing development project, although the business process analyst/architect will be replaced with the particular application-specific analyst/architect role. Brown equates the CoE for a specific technology or application such as BPM, and an overall enterprise architecture team in terms of the mentoring and governance role that they provide. He had a number of case studies of BPM and SOA projects that showed significant ROI, with a BPM/SOA CoE being a key part of each of them.
, at TUCON later this month.
