In my previous post, I wrote about the Business Process Life-Cycle, which looks at a process and its growth to maturity. In this post, I discuss a BPM implementation from an enterprise-wide perspective at a high-level. A enterprise BPM implementation is unlike the traditional software development. For one thing, the end-users need to get involved way too ahead in the game and need to stay in the loop much more than in traditional software development. Second, to achieve the key promise of BPM – agility, it is important (though not always mandatory) to have a services enabled infrastructure as a pre-requisite, and for the organization to be already aware of the concept of a “service”, and to be thinking along those terms.
In terms of the typical phases of implementation, a BPM project follows a slightly different path than traditional software development. In my opinion, a successful enterprise BPM implementation needs to have the following phases:
There are so many niche players with varied offerings that it is imperative for an organization to do its due diligence before selecting a vendor, to ensure that the vendor’s offerings best match the organizations business, BPM strategy, and customer/user alignment. Vendors might adhere to different standards and versions (BPEL, BPMN, etc) and it is important to pick one that aligns with the standardization and interoperability strategy of an organization. Price is a very important factor, and can often play a deciding role in picking software, especially when considering the license and maintenance cost over time, over the targeted number of users. The installation model – installed on-premise or a SaaS model – is another important factor when discussing process-design, process-agility, cost-agility, accessibility, accountability, security, time-to-market, and ROI.
After choosing the software, it is important to plan for a pilot implementation. This is of utmost significance, and the manner in which it is done can decide the success of failure of the entire implementation. The first step in this is to pick the right set of processes. The processes should be representative of the larger set that the organization intends to implement, but should also seek to mitigate the potential risks and doubts that various stakeholders might have. It is useful to pick a process for which current metrics or KPIs are available, so that once the process is implemented, it offers a way to compare. Also, it is a great way to use numbers instead of opinions to satisfy the concerns of various stakeholders. A pilot implementation is a great way to learn the technology and tools, to establish standards, best practices and no-nos, as well as to build a framework that can be leveraged by future processes. There is no better time to validate if the software/tool chosen is the right one for the organization.
The success of the pilot will largely determine the success of the entire project. The pilot can be used as a reference for users to accept BPM as a viable concept, and the tool as a good choice. The users could be internal or external. However, the most important ones are usually the end-users of the process, as their acceptance can be a huge win and a driver for accelerating enterprise BPM implementation. This phase might also involve securing the sponsorship of an executive or a champion to drive this further based on an organizational goal/metric – ROI, user experience, cost, etc. This is also a good time to alleviate any concerns, fix any deal-breakers, or refine the strategy to gain user acceptance if not available or apparent.
Once the users accept the product and vouch for it, it is a good time to expand the processification and BPMization benefits to the rest of the organization. Once this phase begins, there is no turning back. Success though is never guaranteed, and hence caution is prudent. This phase could involve converting the experiences from the pilot phase into the establishment of a formal Center of Excellence to govern, guide and help future process implementation projects within the organization. It is also appropriate to define various roles for a process implementation (Process Architect, Business Analyst, Process Developer, etc) as part of the formalization.
We hope you liked this post about Enterprise BPM Implementation. If you have any interesting observations of your own, feel free to use the comment section below. Follow Princeton Blue on Facebook, LinkedIn, Twitter & Google+ to get BPM-specific updates regularly.