Showing posts with label bpm. Show all posts
Showing posts with label bpm. Show all posts

Wednesday, 5 November 2008

Model Value Analysis

Today I read an excerpt of an upcoming book titled "Business Modeling: A Practical Guide to Realizing Business Value" written by David Bridgeland and Ron Zahavi, available on OMG web site. It discusses a very simple technique to ensure that business modeling does not run into trouble due to Model Value Destruction. Many of us must have heard of failed business modeling exercises in our own or our customer organizations. There are various reasons why business modeling projects fail. These include reasons such as model value destruction, scope failures, straight through modeling, creeping complexity, ugly models, and incompetent modelers. Though the book addresses how each of these dangers can be avoided, the available excerpt provides how model value destruction can be avoided with model value analysis.

Value destruction happens when the company takes an action that has a smaller economic
benefit than the cost of the action. Similarly, building some models incur more cost than the benefits that can be generated out of them, thus resulting into model value destruction. It can be avoided by using Model Value Analysis.

Simply put, model value analysis is a summary of the expected costs and the expected benefits, and a comparison of the two, as described in a spreadsheet. One sheet of the spreadsheet should list all the possible benefits of business modeling against which both estimated one-time and annual time savings should be recorded. There are eight benefits of business modeling as given below.
  1. Communication
  2. Training
  3. Persuasion
  4. Analysis
  5. Compliance Checking
  6. Requirements for software development
  7. Direct Execution
  8. Knowledge Management and reuse
It is not necessary that each modeling exercise should save time (and hence cost) against each one of the benefits listed above though one can discover additional benefits during model value analysis. In the second sheet, one must record all time spent (both one-time and annual) for business modeling against following elements:
  1. Constructing the model
  2. Socializing the model
  3. Maintenance
While hours can be the unit to record both costs and benefits, perhaps dollar value is the better unit to use for comparison by taking into account personnel cost.

While this technique looks so simple, it may consume considerable amount of time and efforts if one employs it for making decision regarding complex business modeling exercise. A good rule of thumb is to spend 1% of the total anticipated modeling time on the model value analysis, to decide whether the other 99% makes economic sense.

BTW, after reading this excerpt, I am now awaiting the release of this book as it seems to have useful content on business modeling. Since it is being published by OMG itself, the quality has to be very good!

Wednesday, 29 October 2008

The Keys to BPM Project Success

Today I read an article titled "The Keys to BPM Project Success", written by Derek Miers and published in Jan 2006 issue of BPTrends. This article describes a recipe for execution of a successful BPM project. In this blog, I am trying to capture the steps of the proposed BPM Project Delivery Framework. The article provides quite a few examples while describing these steps, which are worth reading once to get convinced for significance of each of the given steps.

Step 1 – Establish the Steering Group consisting of executive head of the affected business area, CIO or lead IT executive, BPM program manager (or head of BPM CoE, if exists) and senior LOB managers from the functions directly affected. Conduct the initial Steering Group Workshop to obtain formal commitment from the business, linkage between BPM program & strategy of the organization and tactical agreement on the choice of project & consensus on scope.

Step 2: Identify the suitable target process which has relatively low level of maturity, high impact and low complexity. A good rule of thumb is to ensure that the selected initial project can complete within 3-6 months.

Step 3: Develop the business case that can be tied back to the Key Business Objectives (KBOs) of the organization. Techniques such as Goal Question Metric (GQM) technique developed by Victor Basili and his colleagues can be used to ensure alignment.

Step 4: Gain executive sponsorship

Step 5: Form the BPM Project Team consisting of BPM Project Manager, Senior User from the affected area, one or more SMEs from the LOB area, Lead Business Analysts and IT Specialists.

Step 6: Understand the process by using techniques such as Role Activity Diagrams (RADs) and Object State Transition Network (OSTN) techniques in addition to flow diagram based approaches.

Step 7: Identify breakthrough opportunities such as potential for faster cycle times, enhanced customer service, channel integration, minimizing the number of times of handling the work items,role rationalization, management and monitoring of personnel performance and better exception management.

Step 8: Develop and prototype on the BPM suite

Step 9: Implement and align organizational change

Besides this recipe for sucess, the article also provides a 16-points list of pitfalls to avoid. In all, the article is a good read of anyone interested and/or involved in initial BPM projects in an organization.