Last session of the day, and Meryl Stewart and Kelly Karlen of BlueCross BlueShield of Minnesota talked about maximizing BPM value through business and IT collaboration. They established a shared business-IT objective of enabling the business to manage their frequently-changing business rules to provide agility, while still maintaining environmental stability by following the necessary change management procedures.
They’ve wrapped some procedures around their projects to explicitly call this out, as well as explicit governance layers for processes and rules. Some of this — a big part — is about well-defined roles and responsibilities, such as a business rules steward. They categorize these procedures and methods by collection, execution and optimization stages, and walked us through each of the roles in each of the stages.
In the collection stage, they have a pretty structured way to create business rules and shore them in an enterprise repository; this is independent of their BPM technology, since not all processes end up being automated.
They wanted to make execution more efficient, so combined their RUP methodology with Pega’s RUP-like methodology and lightened it up to create a more agile “RUP Lite” (although as they walk through it, it doesn’t feel so light but it does have fairly frequent code releases). Within that methodology, they have a number of additional roles to work on the business to technology transformation of the execution phase, and definite rules about who can do what types of changes and who does the associated testing. There’s a level of semi-technical analyst who can do a lot of the non-coding changes.
The optimization stage is where business agility happens, but this was addressed pretty quickly and seemed to be some sort of standard change management procedure.
This definitely shows some good software development practices, but there’s nothing particularly innovative here that can’t be replicated elsewhere as long as you can get the collaboration part to work; collaboration is primarily a function of finding people on both sides of the business-IT divide who can see over the wall to the other side, and maybe even straddle the divide somewhat with their skills.
They’ve applied the methodology to a couple of projects and have seen positive ROI, and very few coding changes since most of the process tuning can be done by business users or the semi-technical analysts. In one process, they’ve had 11 rule changes in 4 months with resultant savings of $820k in the improved processes; if IT were to have been involved in these changes, only $126k of the savings could have been realized in the same timeframe due to IT project schedules — a good measure of the value of agility provided by allowing the business to change business rules. Fundamentally, they changed an 8-week IT build cycle to 10 days or less by allowing the business to change the rules, but still following a test and deploy cycle that keeps lT happy.
That’s it for today; there’s a reception, then dinner and a cruise on the Potomac to view the monuments by night. The esteemed Dr. Michael zur Muehlen will not be joining us in spite of being right across the river in Arlington; when I invited him, he gave some lame excuse about just getting back from Seoul. 😉