An SOA odyssey

Thursday, October 26, 2006

Business Process Improvement

While thinking on the subject I thought I'd update the status of our project. We rolled out the final of our four releases (code named "Bread & Butter" and the most complex since it handled all types of money relationships including making payments on sponsorships, setting up new sponsorships with credit cards etc.) at the end of July and experienced a bit of a bumpy ride. After the rollout we were in a hotfix mode for roughly 30 days where we made incremental releases to various components every few days in order to handle issues that were not evidenced by our user acceptance testing. Unfortunately the release schedule was heavily influenced by some external business realities that the team didn't control and which forced us into the tradeoff situation we found ourselves in.

At this point however, the infrastructure has handled over 125,000 business transactions and 3.5M service invocations with system exceptions under 1%. The interesting thing, and the most important of course, is that 70% of the business transactions now go down the happy path and do not involve human interaction. That 30% that do require human interaction, however, are ripe for process improvements and additional incremental automation that will allow that number to shrink dramatically. There are two interesting aspects that came out of this however.

  • First, when you're implementing a business process management solution like this you should probably educate the business that there will be some low hanging fruit that comes out of the statistics generated after the release. As a result, they'll probably want to budget some resources for addressing these things in a final phase of the project. In our case, the project team is set to disband and the resources were not allocated and so the low hanging fruit will have to wait for another project. When that will exactly be is yet to be determined.

  • It's extrememly important to define before the project both the strategy for collection and the kinds of metrics you want to collect. The obvious reason is that these metrics will embody the questions that the business will ask and therefore point to where the process improvements can take place. In our implementation we did not do a thorough enough job of either collection or understanding and as a result there are some holes in our ability to ask the right questions. We're attempting to address some of this in a followup project but as you can imagine it's more difficult at this stage than it would have been if integrated into the early iterations of the project.

    Post a Comment

    << Home