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.