Most organizations seem to follow a similar path to adopting BPM:

First a small “Business Process” department/group is formed to focus on these efforts- discovery phase. In this phase, at the very least the “Core/Strategic”  “As Is” processes for the organization are identified and documented. Existing Process issues and problems are identified and a set of “To be” processes  representing the desired state are also explored. Some  companies may also try for standardization on a Global set of processes.
A BPM Tool may or may not be  selected and if selected a Pilot project on a portion of one of the “Core” processes  is started. In other cases, process improvements may be made using existing applications fulfilling  the process without using a BPM tool (possibly more expensive ).
If a Tool is selected (BPM after all does not necessarily mean automation), in many cases, the Pilot succeeds and  further projects using the BPM tool are started culminating in expanding the initial Business Process Group  into by  a BPM center of excellence . Then there seems to be a point where there is no concrete roadmap/plan to move BPM adoption forward

If going in for a  BPM Tool, then everyone needs to understand clearly what strategic drivers are met with BPM, this needs to be a part of the overall IT strategy.
There need to be roadmaps in place explaining what the future landscape of applications would look like with a BPM tool in place. There should be clear guidelines and policies that state in which cases (Where) and How the  BPM Tool will be used (possible scenarios). These scenarios are not rigid but will grow and refine as expertise with the tool grows.
This way both business and IT will  have a common understanding of where the BPM tool fits into the existing application landscape, what strategic drivers are met by the tool which will help  brainstorm series of   projects that can be started to achieve final objective (“To be” state).

Depending on the organization and the type of  BPM tool selected ( for example-Integration centric, documentation centric, work flow centric, or pure play BPMs), there may be guidelines to use the BPM Tool as the standard Integration platform or Documentation platform for all projects going forward or you, may even replace some smaller niche applications used by a small group by configuring the BPM Tool appropriately.

This means enterprise and business architect groups and of course groups coming up with IT strategy need to be involved in both BPM strategy and selection of the tool.

In further blog posts , I will discuss various ways in which a BPM tool  can be used within an organization. Many of these, may not be applicable  across the board for all organizations, but depending on the business and therefore IT strategy, a mix could work. I welcome comments on the various ways  organizations use a BPM Tool.

Follow