Saturday, March 30, 2013

BPM's Best First Step: Three-Step to Implement BPM Best First Process

BPM has become strategic effort in many organizations today, as business turns to be over-complex and hyper-connected; however, around 70% of BPM projects fail to reach the expected result. Every journey starts with first step, how to select your best first BPM project? There are many parameters in question and what you pick should depend on your organizational context - objective, culture, governance maturity, process maturity, technological competence, political angles, also, how to implement BPM smoothly? Here are three logic steps. 

1. First Best Process Selection 

The best first process is to start with  the one of greatest pressing importance to the business - the process that people care about the most, the process on fire, and likely the one that justified the initial investment in BPM.

  • The Characteristics of Best First Process: The Best First Process to implement with BPM is the one where you have strong buy in from the business sponsors and you can almost guarantee to yourself that the implementation will be a success. Best first process has these characteristics:
    -Has real value
    -Measurable outputs (including ROI)
    -Well defined goals
    -Good learning experience potential 
  • Be "very clear" on the key driver among many and sticking guns to it.  Many BPM implementations come with different "Key Driver". The process selected needs to address "that" key driver for the organization in question. Ironically, the Key driver for the organization going into BPM gets lost in the multiple messages coming from all around once the initiative really kicks off. In the attempt of trying too hard to be successful, the objectives of the first project get overloaded with various "general success criteria".. It could be any of the following:
    - Process heavy on interaction (intra-departmental) and light on technology
    - Process light on collaboration and containing couple of key technological evaluation points
    - Process that directly impacts the KPIs being targeted, but still light in terms of changes
    - Process that demands lowest level of Change Management.     
  • The more systematic approach to the problem of picking up the right process is high-level value chain analysis followed by performance gap analysis. These activities should precede the BPM project and they provide valuable results to assess that the process they select isn't so complex or large that it can't be completed, or the effort will simply be discouraging. Companies often think that starting with an overly complex process first is a good way to see if BPM is of value. While BPM software is most likely capable of managing those complex processes, it takes time to implement those which could lead to a delay in user adoption and immediate ROI. Whatever category (HR, Finance, etc) of processes that BPM can be applied to, start with the less complex and get immediate traction with end users.

2. Well Define Scope of Best First Process 

The process scope need be well defined. This way a major business problem can be addressed hand-on while garnering support from across the organization.

  • Finding the balance comes with experience. The process need have high business impacts with low risk to the business. Unfortunately high impact usually means high risk. It's like heavy-lifting: picking up a weight that is too heavy for you (high stakes) mean a risk of not qualifying; yet a weight too light means loosing the competition. When facing tough choice, one would rather accept a risk of hitting a problem that turned out to be more complex than expected than choosing an easy journey. The customer will appreciate your efforts anyway in the former case and probably give you an opportunity to move on. But in the latter case there is a risk to hear at the end of the project: "So what? We are not impressed much."     
  • Derive simple objectives for that first project from a view of the overall objectives of BPM for the enterprise. The success in the first projects is crucial. as in the larger scheme, the first few projects are going to set the pace and the stage for further BPM success - so it is important to derive simple objectives for that first project from a view of the overall objectives of BPM for the enterprise. A smooth path to the roll out is not enough to call the first BPM project a success. It is equally important for the project to be able to hold good potential for a learning experience for future projects. 
  • Capture the Dynamic Nature of BPM: Many times, a process CAN be well-defined but is NOT well-defined yet. Sometimes a prospect suggests: "There is the process X that we know from top to bottom. We already implemented it in system Y. Now let's implement it in BPM and look at the difference.". However, doing project this way, you won't be able to demonstrate the dynamic nature of BPM - it'll be process automation, not process management.

3. Low Complexity Fragment of High Complex Process 

High business impact process usually means high complexity. From the other hand, you obviously cannot afford high complexity (and hence high costs and huge timeframes) at the first project.

  • The solution for this dilemma is LOW COMPLEXITY FRAGMENT of high complex process. Find a process with critical business issue behind it, whatever complex it is and define it as the outer scope of your project. Then find a fragment of that process that you'll be able to cope with at your first project within reasonable timeframe and costs. 
  • Set Right Project Milestones: Typically critical processes are complex and you never reach the end, thus this have an impact how process is designed and implemented, ultimately may become a never ending story. It means that caution is needed the way the project is managed in a way that users, champion and sponsor can feel the results on a timely basis. Otherwise people will disbelieve in options taken. Once BPMS can provide slices of improvement step-by step, and sometimes it is possible to deploy parts of the to-be process running with the as-is one. 
  • Start with IT Process as usually IT is in charge of BPM: since 99 out of 100 times IT will be in charge of implementing the first BPM project - IT is just as much a business as any others, and has many, many processes - from the unstructured to the highly structured (think process management vs. automated workbook) - and even has a well accepted process guideline such as ITIL. Let IT find a process in their own department, analyze it, implement it in BPM and deploy it. It will be great learning experience - and when they get to the next non-IT process. In reality, very few (if any) IT departments use BPM for their own processes.     
In order to take the solid first, best step in BPM journey, think broader than "process" in its simplest form, plan for the view of the overall objectives of BPM for the enterprise, leverage key business drivers, accumulate knowledge and best practice, and set up the right milestones to measure result.  


Easy steps of BPM implementation is given in the blogs. Thanks for the good effort. Keep updating your blog regularly.

Post a Comment

Twitter Delicious Facebook Digg Stumbleupon Favorites More